GNOME Bugzilla – Bug 340899
Adjust Time: F-Spot sets time to wrong time.
Last modified: 2010-06-08 09:44:21 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.
Any comments on this one?
See bug #332025 and especially comment 2 there.
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.
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.
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.
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.
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)
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.
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.
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.
> 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....
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.
*** Bug 499832 has been marked as a duplicate of this bug. ***
Whichever timezone the camera is set to F-Spot MUST NOT modify DateTimeOriginal.
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.
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.
*** This bug has been marked as a duplicate of bug 332025 ***