GNOME Bugzilla – Bug 517811
Display Date and Time in local time zone
Last modified: 2009-11-05 15:14:17 UTC
When I browse my images, f-spot shows the exif tag 0x9003 (Date and Time (original)) underneath the images. For my images, this always (?) seems to be one hour off. The tag 0x9004 "Date and Time (digitized)" is correct though. It would be better, if f-spot would display this tag. Other applications also seem to use this tag. Eg. when I use gthumb and have it insert the time/date of the picture in the name, it uses this tag and not 0x9003. So in interoperability, this would also be better. You can find an example image at http://s3.amazonaws.com/public-files.askwar/f-spot/image.jpeg . Other information: Using SVN r3706 on Gentoo Linux.
Are you aware that f-spot stores date/times in UTC?
No, I'm not. If so, why doesn't f-spot *display* date/time in local time zone (this would be +1 for me right now in Switzerland)? Anyway - if you check the EXIF of the sample image, you'll find: --($:/dev/shm)-- LC_ALL=C exif image.jpeg EXIF tags in 'image.jpeg' ('Motorola' byte order): --------------------+---------------------------------------------------------- Tag |Value --------------------+---------------------------------------------------------- Manufacturer |CASIO COMPUTER CO.,LTD Model |QV-R61 Orientation |top - left x-Resolution |72.00 y-Resolution |72.00 Resolution Unit |Inch Software |f-spot version 0.4.2 Date and Time |2008:02:20 09:27:32 YCbCr Positioning |centered Unknown | Compression |JPEG compression x-Resolution |72.00 y-Resolution |72.00 Resolution Unit |Inch Exposure Time |1/60 sec. FNumber |f/2.8 ExposureProgram |Portrait Exif Version |Exif Version 2.21 Date and Time (origi|2008:02:16 10:14:52 Date and Time (digit|2008:02:16 11:14:52 ComponentsConfigurat|Y Cb Cr - Compressed Bits per |4.20 Exposure Bias |0.00 EV MaxApertureValue |3.00 EV (f/2.8) Metering Mode |Pattern Light Source |0 Flash |Flash fired, auto mode. Focal Length |8.0 mm User Comment |Unicode FlashPixVersion |FlashPix Version 1.0 Color Space |sRGB PixelXDimension |1872 PixelYDimension |2816 File Source |DSC Custom Rendered |Normal process Exposure Mode |Auto exposure White Balance |Auto white balance Digital Zoom Ratio |0/0 Focal Length In 35mm|39 Scene Capture Type |Portrait Gain Control |Low gain up Contrast |Normal Saturation |Normal Sharpness |Normal InteroperabilityInde|R98 InteroperabilityVers|0100 --------------------+---------------------------------------------------------- EXIF data contains a thumbnail (8203 bytes). f-spot displays "2008:02:16 10:14:52", which seems to be "Date and Time (origi" (ie. 0x9003).
(In reply to comment #2) > No, I'm not. If so, why doesn't f-spot *display* date/time in local time zone > (this would be +1 for me right now in Switzerland)? because until mono 1.2.5 timezone wasn't supported. now that many distributions include recent versions of mono the dates will be handled correctly. closing then. *** This bug has been marked as a duplicate of 340903 ***
(In reply to comment #3) > (In reply to comment #2) > > No, I'm not. If so, why doesn't f-spot *display* date/time in local time zone > > (this would be +1 for me right now in Switzerland)? > > because until mono 1.2.5 timezone wasn't supported. now that many distributions > include recent versions of mono the dates will be handled correctly. I don't understand. I've got Mono 1.2.6. How are the dates handled correctly now? I don't think that displaying time in UTC is good - it would be better, if local time would be displayed. > closing then. > > *** This bug has been marked as a duplicate of 340903 *** > Reading through that bug, it really sounds as if this is dupe of that.
(In reply to comment #4) > I don't understand. I've got Mono 1.2.6. How are the dates handled correctly > now? I don't think that displaying time in UTC is good - it would be better, if > local time would be displayed. mono 1.2.5 is a requirement. code into f-spot must be developed for TZ support. this is being worked, and will be released in the (hopefully near) future.
(In reply to comment #3) > > because until mono 1.2.5 timezone wasn't supported. now that many distributions > include recent versions of mono the dates will be handled correctly. > > closing then. > > *** This bug has been marked as a duplicate of 340903 *** I disagree that this is necessarily a duplicate of bug 340903. It certainly could be fixed while the whole f-spot-mangles-exif-data mess is cleaned up, but this really has nothing to do with whatever date is decided to be stored internally and can be fixed before that other mess is fixed (3 years waiting already). This bug, as I read it, specifically deals with the display format of the date the photo was taken and that the display is not adjusted for the local timezone. i.e. when I look at the time a photo was taken, the time I see should be the local time of one of either the timezone it was taken in or the timezone it is being viewed in. Right now, it's neither. Which is displayed, when timezone taken in and timezone viewed in are different, I'm not sure I specifically care about, but perhaps it should be user selectable. In any case, the display time should probably show which timezone it's localizing the time for.