After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 518172 - Wrong time when importing twice
Wrong time when importing twice
Status: RESOLVED DUPLICATE of bug 340903
Product: f-spot
Classification: Other
Component: Import
SVN
Other Linux
: Normal normal
: ---
Assigned To: F-spot maintainers
F-spot maintainers
Depends on:
Blocks:
 
 
Reported: 2008-02-23 01:29 UTC by Eitan Isaacson
Modified: 2008-03-14 09:46 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Eitan Isaacson 2008-02-23 01:29:11 UTC
F-Spot normalizes the photo's time to UTC based on the computer's time zone.
This is fine, but it also looks like F-Spot writes the normalized datetime to exif, and then if I would re-import the photo the time would be pushed further past UTC.

For example, I am in GMT-8, so if I take a picture at 14:30, and import it, F-Fpot will normalize it to 6:30, but if I re-import the file from F-Spot's photo dir into a new installation, It adjusts the time 8 hours further, so now the photo is dated at 22:30 from the previous day.
Comment 1 Maxxer 2008-02-23 12:58:45 UTC
until TimeZone support will be included in f-spot there's no way to avoid this.

this is not a new bug, but a well known one. can we mark as dup of bug 340903?
Comment 2 Eitan Isaacson 2008-02-23 21:11:17 UTC
I see this problem as much easier to solve than bug 340903.
At import time F-Spot should look at the EXIF "Software" field.
If it is "f-spot", and if it is a version that is known to adjust the EXIF date - don't adjust it further.
If "f-spot" doesn't appear, adjust time to UTC.

Simple!
Comment 3 Maxxer 2008-02-25 09:01:30 UTC
this is a workaround, not a solution. if in the meantime i change or erase the exif data then your check would fail.
Comment 4 Maxxer 2008-03-14 09:46:12 UTC

*** This bug has been marked as a duplicate of 340903 ***