it s storing the photo in the utc date, I need to think about this a little.

I was bitten by this recently; one of my cameras, a pentax optio S4, has the option to specify the timezone you're currently in; a "home" timezone, and a "world" timeone, so when you're travelling, you can say "now i'm in tokyo" and it'll take photos and set local time.

now it sucks that EXIF doesn't do timezones at all, but now i have some photos that are in japan timezone, and some in sydney, and regardless of where they were taken, f-spot has assumed that they were all in sydney and *then* adjusted to GMT from +1100.

I thought that setting all of my cameras to GMT would solve the problem, but in actual fact that makes it worse, because F-spot doesn't know this and still subtracts 11 hours from the timestamp :-)

I was a little surprised that f-spot would try to mangle the times at all, i expected that it would trust that the camera was right and just leave it, mainly because there is no timezone data in EXIF so you really have no idea if the time in the photo has any relevance to the timezone of the computer.

My vote is to leave the timestamps well alone, and let the user modify them if necessary with the new date adjust dialog.

I tried to raised the severity of this one since as it is now, the timestamp is  mangled by F-Spot, and no way to recover it. But my authority do not allow me to do it.

Also see Bug #332005

Raised severity.

Also see 
bug #340903 – Adjust Time: Changing internal photo time to UTC is not good.
bug #340899 – Adjust Time: F-Spot sets time to wrong time.

Several Ubuntu users have identified this problem. 
Please see: http://ubuntuforums.org/showthread.php?t=377713 

Fyi.

*** Bug 475478 has been marked as a duplicate of this bug. ***

I've just been bitten by the same problem - it's particularly annoying living in New Zealand where the high UTC offset means almost half my photos end up on the wrong date. Seems to me this is a case of software trying to be too clever, and getting it completely wrong - if my camera says the photo was taken at 11:00, that's when the photo was taken. Not 23:00 the previous night.

Any chance of this rather buggy behaviour getting changed? I mean, I can see what the objective of the current code is, but as it stands, it doesn't work. I'd assume most users have their camera time set to their local timezone - is there a reason not to make the same assumption in f-spot?

Incidentally, is there a reason this bug is still listed as UNCONFIRMED, a year and a half after first being logged, and with posts by developers indicating they're aware of the problem? Is anything actually happening with it? It seems to be a pretty serious bug, but there's not been much activity on it (or any of it's siblings) for over a year...

Incidentally, I would guess that the reason for the length of time passing is due to time constraints and the inability of the developers to defy physics.  I am sure they would welcome some additional help to increase the amount of time to focus on all the bugs!

2 quick comments:
- we're not currently using the NEW or UNCONFIRMED status to triage bugs in the project.
- all the 'time' and 'timezone' issues aren't simple ones. And the .NET 2.0 framework doesn't provide any support for this (except the local and GMT timezones). Instead of cooking a f-spot only workaround for this, we implemented the .NET 3.5 TimeZoneInfo which is now distributed as part of mono 1.2.5. And right now, we can't make f-spot depends on mono 1.2.5... that's for the "not so much activity"

I realise coming up with a perfect solution for all the timezone issues isn't trivial. But if the current behaviour is as wrong as it appears to be, why not in the interim support the most common scenario where you don't need to worry about timezones at all?

Indeed, I'd be perfectly happy to patch that entire feature out of my own copy of F-Spot, if someone would show me which lines to delete. I'm not very familiar with C#, but am I correct in thinking the offender is the single call to jimg.SetDateTimeOriginal() in PhotoStore.cs?

Created attachment 95712 [details] [review]
Stops converting dates between UTC and localtime

Ok, this patch is probably far from optimal for the project developers, but seems to does what I want it to do - i.e just assume everything is local time, and stop trying to do unwanted timezone conversions.

Thanks for the patch Simon.
I may not understand the issue fully, but it seems like in order to convert from localtime(what my exif has) to GMT (which f-spot is generating), must take some code.  The simplest would be to just do nothing, and just use the date as-is from the exif data.

I think the timzone issues and working with cameras that have timezone offsets with their internal clocks set to GMT would be great for a future release, once this can be worked out between f-spot and mono.

For me, this is a show-stopper in an otherwise perfect app, which there really is no equal in the linux world.  It seems for this issue its best to do it the gnome way, keep it simple, and just assume the date in the exif data is the correct one, regardless of timezone, localtime, and whatever else...

Created attachment 100495 [details] [review]
Patch ported to version 4.1

I've created a new patch for version 0.4.1 based on the previously attached one.  Please review in case there is something I've missed.

Just checked my mono version on Gutsy.

bengt@lappis:~/scripts$ mono --version
Mono JIT compiler version 1.2.4 (tarball)

So it looks like we have to wait another year or probably more before we get a good solution to this problem.

I do agree that for me, it would be have been much better to just keep the EXIF timestamp as it was. 

I think I'm seeing the same problem with a Panasonic FX33. Home timezone correctly set to UTC+7 on both the camera and in Ubuntu Gutsy. However, after importing f-spot shows all timestamps being 7 hours too early.

It would be great to have an option that works with newer models of cameras (timezone aware) to turn off f-spots default behavior easier in the import dialog or as a global preference - this problem is just going to get worse as more users start using newer camera models.

I got bitten by this bug, too. I used the following command to reset my timestamps, as it seems that F-spot only affects the "DateTimeOriginal" tag, not the "CreateDate" tag. You'll need to install exiftool if you don't already have it. The Debian/Ubuntu package for it is libimage-exiftool-perl

cd <TOPMOST_PHOTO_DIRECTORY>
exiftool -P -r '-CreateDate>DateTimeOriginal' *

This may or may not work for you. I highly recommend that you create a backup copy of your photo directories before executing this command.

For me this bug appears when I use the "Photo->import" menu item and import from a folder on my hard disk. On the other hand, when I plug in my camera in an USB port, it is automatically detected, and when I choose to import the pictures, the date is not mangled.

I am using f-spot 0.4.3.1 on Ubuntu 8.04

Severity should be changed to 'Critical', because this bug causes loss of data.

I agree with Marcus Sundman, this bug causes data loss and should thus be marked "Critical".

*** Bug 572234 has been marked as a duplicate of this bug. ***

i agree with most of the comments here but particularly Comment #13 from jason fuchs...

whatever the reasons are for f-spot to INTERNALLY use UTC time, as opposed to local time [which seems unlikely], there can be NO reason to alter the exif DateTimeOriginal field data.

this is such an important 'bug' [feature?] that it renders an otherwise superb program 'useless' until it is corrected...

for example...

if one unchecks 'write meta data' then 'DateTimeOriginal' is NOT altered in any way BUT one loses the ability to add 'tags', 'comments' etc which reduces f-spot to a simple browser/viewer

if the f-spot developers could explain the problem they are having then maybe someone could offer some help

Can't F-Spot just pretend everything is already in UTC instead of breaking time stamps?  Until this bug is fixed, even those who need timezone support will be adversely affected.  I agree with those who said this bug is critical.

Since three years wasn't long enough for the developers (to whom I am grateful) to solve, I'd like to propose a chip-in.  If the developers agree that a chip-in would help to free up their time, I would happily donate to the cause.

http://launchpadlibrarian.net/35518041/no-timestamp-adjust.patch is a patch from Steve McGrath, posted to the Ubuntu bug tracker at https://bugs.edge.launchpad.net/ubuntu/+source/f-spot/+bug/175191/comments/22


It would be great if this could be applied, even if it is just a temporary fix. At the moment, f-spot continues to silently corrupt timestamps for every user with a modern camera that supports timezone settings (probably every new model of camera released over the last 4 years), as f-spot is trying to correct timestamps that are already correctly stored in UTC.

a little advice would be welcome here.

New comer on Linux Ubuntu here (Jaunty & Karmic). I am currently located in Japan (GMT +7)

I tag my photos using Exif (date_time) with pyRenamer. When I import them in F-Spot, Exif is wrong, Date/time in the thumbnails are wrong (surprise!).

I have followed the bug threads on Launchpad to end here.

I wonder why it takes so long for the developers of the current default photo software bundled with Linux Ubuntu to make the application display the correct time zone of one's location? I might be an insignificant end user, still I expect to rely on my photo software.

Unfortunately I don't know how to apply a patch (Steve McGrath), I someone would be nice enough to guide me, I will be grateful.

as of 0.6.2, f-spot now doesn't modify photo date anymore.

*** Bug 340899 has been marked as a duplicate of this bug. ***