GNOME Bugzilla – Bug 345236
Adjusting time introduces offset of 100 years
Last modified: 2018-07-01 15:38:24 UTC
Please describe the problem: A photo with date 2006-06-16 was edited using 'adjust time' to somewhere in march 2006. Now the image lives in march 1906. The 'adjust time' window offered to adjust the date with a DD-MM-YY format, while the current time was displayed in DD-MM-YYYY. The problem did not occure for photo's of the same set where the calendar widget was used to adjust the date, just when the text field was used. However, trying to correct it with the calendar widget did not work. Also, entering 2006 in YYYY did not work. The locale was: LANG=nl_NL.UTF-8 LANGUAGE=nl_NL:nl LC_CTYPE="nl_NL.UTF-8" LC_NUMERIC="nl_NL.UTF-8" LC_TIME="nl_NL.UTF-8" LC_COLLATE="nl_NL.UTF-8" LC_MONETARY="nl_NL.UTF-8" LC_MESSAGES="nl_NL.UTF-8" LC_PAPER="nl_NL.UTF-8" LC_NAME="nl_NL.UTF-8" LC_ADDRESS="nl_NL.UTF-8" LC_TELEPHONE="nl_NL.UTF-8" LC_MEASUREMENT="nl_NL.UTF-8" LC_IDENTIFICATION="nl_NL.UTF-8" LC_ALL= The only solution we found was to start F-Spot with a en_US local. Now the year could be corrected. I could not really debug this further, because it happened to my sister's F-Spot. I could not reproduce this myself, even with the same image she send me from F-Spot via e-mail (I assume this sends the exact same image with metadata intact). My F-Spot showed it in 2006 after import. This is of course related to bug #340890 but the more critical problem is not described there. Maybe this bug is only triggered with some specific images. I think this image did not have any EXIF data when my sister imported it. Steps to reproduce: I could not reproduce it myself. Actual results: The year gets offset by -100 years. So a date in 2006 will end up being in 1906. Expected results: I would expect the date to just stay in 2006 of course. Does this happen every time? No, only when entering the date directly in the text field (as opposed to using the Gnome calendar widget). And even then I cannot reproduce it myself. Other information:
I was unable to reproduce this bug on F-Spot 0.2.1 dotancohen@ubuntu:~$ locale LANG=he_IL.UTF-8 LANGUAGE=he_IL.UTF-8 LC_CTYPE="he_IL.UTF-8" LC_NUMERIC="he_IL.UTF-8" LC_TIME="he_IL.UTF-8" LC_COLLATE="he_IL.UTF-8" LC_MONETARY="he_IL.UTF-8" LC_MESSAGES="he_IL.UTF-8" LC_PAPER="he_IL.UTF-8" LC_NAME="he_IL.UTF-8" LC_ADDRESS="he_IL.UTF-8" LC_TELEPHONE="he_IL.UTF-8" LC_MEASUREMENT="he_IL.UTF-8" LC_IDENTIFICATION="he_IL.UTF-8" LC_ALL= dotancohen@ubuntu:~$
This problem still exists in 0.6.1.1. In my case, my camera battery got low enough that the camera time reset to 3/12/2153 4:19AM. I'm still not sure how I got the times set correctly, but they got further and further in the future, and then went to year 401. Based on one comment above, changing the LANG to en_US allowed me to set the date directly. Previously LANG was not set and all LC_ vars were POSIX.
f-spot is not under active development anymore, has not seen code changes for five years, and saw its last tarball release in the year 2010. Its codebase has been archived: https://gitlab.gnome.org/Archive/f-spot/commits/master Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.
While closing this is probably the right resolution, f-spot is not dead. There have been no releases, and most distros have dropped it, but there is definitely active development - https://gitter.im/mono/f-spot is probably the best place to follow activity.