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 340899 - Adjust Time: F-Spot sets time to wrong time.
Adjust Time: F-Spot sets time to wrong time.
Status: RESOLVED DUPLICATE of bug 332025
Product: f-spot
Classification: Other
Component: Editing
CVS
Other Linux
: Normal critical
: 0.7.0
Assigned To: F-spot maintainers
F-spot maintainers
: 499832 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-05-07 08:19 UTC by Bengt Thuree
Modified: 2010-06-08 09:44 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Bengt Thuree 2006-05-07 08:19:44 UTC
In this case you are based in Melbourne, and traveled to China.
China is two hours after Melbourne, but you forgot to change the time in the camera.
You take some pictures, and load them into your computer (which time you have changed to Chinese time).
You use F-Spot to manually change the time with two hours. (instead of picture taken at 22 hours, it was taken at 20 (8 PM))

1) Select one photo
   Date Time Original (MetaBrowser and Eye) : 2006:04:24 22:30:28
2) Start adjust time
   Current Date/Time 24/04/2006 10:30:28 PM 
   Adjusted date     24/04/06   14:30
   difference        00:00:00

3) Set Date to 24/04/06   20:30:28  --> difference 06:00:28
   Press ok.
   ---> DateTimeOriginal 2006:04:25 04:30:56

F-Spot changes the timestamp to something completely different. 
It's seems to do the following:
1) Setting the default Adjusted Date/Time to be the Original Time but in UTC instead (-8 hours in this case).
2) Since I manually put in 20:30:28 as the actual time, F-Spot calculates that the difference between 14:30 (UTC) to 20:30 (new time) is 6 hours, and quite happily adds it to the Original Time (22 + 06 --> 04:30 next day).

Do I need to mention, this is not the result I expected.
Comment 1 Bengt Thuree 2006-05-15 15:47:57 UTC
Any comments on this one?
Comment 2 Bengt Thuree 2006-05-18 04:42:12 UTC
See bug #332025 and especially comment 2 there.
Comment 3 Larry Ewing 2006-05-24 18:48:11 UTC
There are serious bugs in the gnome date edit widget and probably a small bug in the f-spot time code. If someone wants to look into fixing thie, especially replacing the gnome date edit widget I'd be happy to explain the details.
Comment 4 Bengt Thuree 2006-05-25 00:55:15 UTC
I guess I can volunter, but no promises and no deadlines :).
Drop me a mail...

Still do not understand how gnome date edit widget can cause problem that are mainly due to possible three different timezone issues.
Comment 5 Larry Ewing 2006-07-20 19:49:58 UTC
Bengt, I think the road to fixing the time issue are something like this.  Let's get some date/time related widgets that give us accurate values while they are being edited and allow easy selection of timezones or photograph locations then move the image DateTime logic to using a custom class that keeps track of what timezone information we do know (the important distinction being unknown or known) then we can audit all the places we use datetimes and solve this mess properly.
Comment 6 Dotan Cohen 2006-09-26 14:18:56 UTC
Why should timezone information even be relevant? If it's a technical reason then it's a bug. If it's deliberate then it should be removed.
Comment 7 Bengt Thuree 2006-09-26 14:40:00 UTC
We have three different clocks here.
1) Computer
2) Camera
3) Location where we took photo

You need to know all three timezones to be able to set the time correctly.

Unless, you decides to totally ignore the timezone (and UTC), and only go with local time. Then it is much easier.

I would recommend that F-Spot stores the local time in EXIF, and with a correct Timezone value in XMP. Or only local.
(I have still not heard a compelling argument to keep everything in UTC)
Comment 8 Dotan Cohen 2006-09-26 19:41:27 UTC
We have three different clocks here.
1) Computer
2) Camera
3) Location where we took photo

1) Computer time has nothing to do with the hour that the photo was taken.
2) Camera SHOULD BE ASSUMED TO BE "Location where we took photo".
3) Location where we took photo IS important- this is the one that matters.

I vote that we go with camera time. I took a trip to Spain last month. When I realised in the middle of the trip that I forgot to move the camera's clock back one hour, I decided to leave it that way for the remainder of the trip with the intention of moving all the photos back one hour. This seems most logical.

The theoretical situation where somebody flies quickly from NY to LA and has pictures taken last shown first is borderline absurd. It _might_ happen, but it's a remote enough possibility to ignore it.
Comment 9 Bengt Thuree 2006-09-26 21:37:13 UTC
Yes, The location time is the key one.

But if you start fidling with timezone's, you will have the three above ones to consider.

Consider the following use case:
You live in Australia (Which means your laptop, and camera  is on Australian timezone). 
You fly to Europe on vacation, with a stopover of 3 days in China on the way. You forgot to change the time of the camera.
When you reach Europe, you change the timezone to a europe one on the laptop.
Now you import the photos to F-Spot, and consequently you have three different timezones to consider if you want to change to UTC, or add timezone information.

If you decide to only use local time of the photo, it is much easier.
Comment 10 Bengt Thuree 2007-04-13 16:24:29 UTC
Just added 1400 scanned photos, and manually changed the time on every one of them.

I was not to happy when I realized that when I set the time to be 28 Jun 1999, f-spot in fact set it to 29 Jun 1999 in the photo (EXIF).
I am based in Melbourne.
Comment 11 Nils Pickert 2007-11-16 12:40:49 UTC
> 2) Camera SHOULD BE ASSUMED TO BE "Location where we took photo".

No. I have my camera set to UTC, as it makes it easier to sonchronise with GPS data and I don't have to bother about daylight savings time. You should be able to set the timezone your camera is set to.

When I travel, I usually don't bother to change my camera, usually I completely ignore setting the time of most of my technical devices except my watch....
Comment 12 Bengt Thuree 2007-11-21 18:26:30 UTC
Any news on the new Import dialog? 
Any mockups which we can comment on perhaps?
Hope we will be able to indicate TIMEZONE on import for the photos.
As well as to change the timzone later in Adjust Time gui, since the import might have had a few different timezones in it.
Comment 13 Maxxer 2007-11-26 22:28:00 UTC
*** Bug 499832 has been marked as a duplicate of this bug. ***
Comment 14 Marcus Sundman 2008-11-18 23:33:02 UTC
Whichever timezone the camera is set to F-Spot MUST NOT modify DateTimeOriginal.
Comment 15 Mike 2009-01-06 09:34:56 UTC
OK, 1,400 beats me, but I just dealt with this with 388 photos. Besides having a timezone related issue (as above), my camera clock was wrong, so I had to adjust for that too. Between these two issues, I've just lost one heck of a lot of time and effort. Since the adjust time feature has worked in the past, I assumed it wasn't the problem, and tried adjusting the time on the pictures twice!

Is there any hope that this bug will be fixed any time soon? It's clearly a critical one, and it's on the books for more than 2 years now!

At this point, I would rather f-spot not have an adjust time feature at all, since the one included seems to work, and then messes everything up. If it weren't there, I'd go to other products, get it done, and move on...

Any hope, or is anybody working on this? I'd be happy to help however I can.
Comment 16 Mike 2009-01-08 07:48:26 UTC
Just a follow up, the suggestions at Bug 332025 sum this up pretty well. Ignore timezones, import using EXIF data, and let users correct as needed.
Comment 17 Maxxer 2010-05-19 08:13:25 UTC

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