Re: Time Zone.

[Stephane Delcroix <stephane delcroix org>]

proper timezone support is still high on my priority list.
about your crash, please report a bug

regards

s

On Sun, 2008-04-27 at 23:41 -0400, Pat Suwalski wrote:
> Hello,
> 
> I've brought this issue up before, but now after upgrading to Ubuntu 
> 8.04 my workaround no longer works. So I'm bringing it up again.
> 
> When one imports photos into f-spot, it modifies the actual photo exif 
> and changes the time to what the time was at UTC. I worked around this 
> bad manipulation of exif time by telling f-spot to not write metadata 
> back to the file.
> 
> The issue, however, is that my displayed date, as well as the date 
> directory hierarchy where photos are imported to, is still broken, at 
> least after 19:00 EST.
> 
> My solution to this has always been to run f-spot with:
> 
> 	TZ=UTC f-spot
> 
> That way the date and directory structure was never mangled.
> 
> However, f-spot now crashes as with the attached log when TZ is modified 
> thusly.
> 
> I still think it's inappropriate to change the exif date to UTC. It 
> really does not solve problems regarding date during travels or when 
> photos are sent from another timezone and imported.
> 
> Can f-spot be made to never modify the time at import? Does anyone have 
> a more immediate workaround to the problem?
> 
> --Pat
> plain text document attachment (f-spot.log)
> Stacktrace:
> 
>   at FSpot.Global..cctor () <0xffffffff>
>   at FSpot.Global..cctor () <0x0000d>
>   at (wrapper runtime-invoke) FSpot.Defines.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff>
>   at FSpot.Driver.Main (string[]) <0xffffffff>
>   at FSpot.Driver.Main (string[]) <0x00144>
>   at (wrapper runtime-invoke) FSpot.Driver.runtime_invoke_int_string[] (object,intptr,intptr,intptr) <0xffffffff>
> 
> Native stacktrace:
> 
> 	f-spot [0x51bb67]
> 	f-spot [0x43dacd]
> 	/lib/libpthread.so.0 [0x7f54aceb97d0]
> 	/lib/libc.so.6(memcpy+0x60) [0x7f54ac944d50]
> 	f-spot(mono_breakpoint_clean_code+0x1b) [0x42725b]
> 	f-spot [0x43f78d]
> 	f-spot [0x44005e]
> 	[0x40b4b15b]
> 
> Debug info from gdb:
> 
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> [Thread debugging using libthread_db enabled]
> [New Thread 0x7f54adb997a0 (LWP 14259)]
> [New Thread 0x417c6950 (LWP 14261)]
> [New Thread 0x40347950 (LWP 14260)]
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> (no debugging symbols found)
> 0x00007f54ac965c4b in fork () from /lib/libc.so.6
>   3 Thread 0x40347950 (LWP 14260)  0x00007f54aceb8e81 in nanosleep ()
>    from /lib/libpthread.so.0
>   2 Thread 0x417c6950 (LWP 14261)  0x00007f54aceb5b99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
>   1 Thread 0x7f54adb997a0 (LWP 14259)  0x00007f54ac965c4b in fork ()
>    from /lib/libc.so.6
> 
> Thread 3 (Thread 0x40347950 (LWP 14260)):
> #0  0x00007f54aceb8e81 in nanosleep () from /lib/libpthread.so.0
> #1  0x00000000004b8f4f in ?? ()
> #2  0x00007f54aceb13f7 in start_thread () from /lib/libpthread.so.0
> #3  0x00007f54ac99fb2d in clone () from /lib/libc.so.6
> #4  0x0000000000000000 in ?? ()
> 
> Thread 2 (Thread 0x417c6950 (LWP 14261)):
> #0  0x00007f54aceb5b99 in pthread_cond_wait@@GLIBC_2.3.2 ()
>    from /lib/libpthread.so.0
> #1  0x00000000004bb585 in ?? ()
> #2  0x00000000004bdb37 in ?? ()
> #3  0x00000000004cbc03 in ?? ()
> #4  0x000000000046b3c1 in ?? ()
> #5  0x00000000004855c3 in ?? ()
> #6  0x00000000004cb287 in ?? ()
> #7  0x00000000004e07d2 in ?? ()
> #8  0x00007f54aceb13f7 in start_thread () from /lib/libpthread.so.0
> #9  0x00007f54ac99fb2d in clone () from /lib/libc.so.6
> #10 0x0000000000000000 in ?? ()
> 
> Thread 1 (Thread 0x7f54adb997a0 (LWP 14259)):
> #0  0x00007f54ac965c4b in fork () from /lib/libc.so.6
> #1  0x00007f54ad334d6d in ?? () from /usr/lib/libglib-2.0.so.0
> #2  0x00007f54ad3358df in g_spawn_sync () from /usr/lib/libglib-2.0.so.0
> #3  0x00007f54ad335d98 in g_spawn_command_line_sync ()
>    from /usr/lib/libglib-2.0.so.0
> #4  0x000000000051bbf9 in ?? ()
> #5  0x000000000043dacd in ?? ()
> #6  <signal handler called>
> #7  0x00007f54ac944d50 in memcpy () from /lib/libc.so.6
> #8  0x000000000042725b in mono_breakpoint_clean_code ()
> #9  0x000000000043f78d in ?? ()
> #10 0x000000000044005e in ?? ()
> #11 0x0000000040b4b15b in ?? ()
> #12 0x0000000000000000 in ?? ()
> #0  0x00007f54ac965c4b in fork () from /lib/libc.so.6
> 
> 
> =================================================================
> Got a SIGSEGV while executing native code. This usually indicates
> a fatal error in the mono runtime or one of the native libraries 
> used by your application.
> =================================================================
> 
> _______________________________________________
> F-spot-list mailing list
> F-spot-list gnome org
> http://mail.gnome.org/mailman/listinfo/f-spot-list