Changed title.

Also, another option, is to keep the time as it is stated in the picture it self.
That is do not convert the time to UTC.

This is an issue that needs to be resolved as soon as possible I think.

See bug #332025 and especially comment 2 there.

Most cameras (read 'my camera') do not handle timezones.

So either the user set it to his local timezone (most of them), or to UTC. But from my experiences and discussion with digital photographers (read professional photographers), they prefer to change the time of their cameras according of the local time.

I don't think that choosing a default is a good policy.

We probably need to let the user say in which timezone the picture was shot.

e.g.
- 'This picture was shot in Local Time'
- 'My camera is set to UTC, and I was in that timezone'

Whatever the option whe choose, whatever the part of the world the photo is shot, when I shoot a clock saying 'it's noon', f-spot should say 'the photo was shot at noon'

I think there are two main things that are important to f-spot users in this respect:

First, f-spot should show the local time that the picture was taken in.  As Stephanie points out, if a picture of Big Ben is taken at noon in London, f-spot should tell the user that the picture was taken at noon, even if the user is in China by now.

On the other hand, most users would probably prefer to see their pictures in the order they were taken.  This comes into play when users travel across time zones.  For example, if a user takes a picture in New York City, then quickly flies to Los Angeles, he would still want to see his New York pictures before his Los Angeles pictures, even though the local time of the Los Angeles picture would be earlier than the local time of the New York pictures.

In short, a pictures should be displayed with their local time (and time zone), but ordered by their time in UTC.  (Or at least, users should have the option of doing things this way, since it seems logical and convenient.)

I like Bengt Thuree's idea for making this simple for users.  When importing photos, allow the user to simply specify the time zone that the camera is in, and the time zone that the pictures were taken in.  F-Spot can figure out the rest easily.  Perhaps users would have the option of whether or not the EXIF data should be changed to UTC or left alone?

I agree. I noticed this bug with F-Spot today, and it's driving me mad.

I'm a Gaim developer and I had similar problems with my IM logs a while back. I fixed it like this:

Store the timestamp for the log in local time, and store the offset. For display, the logs are shown with the original timestamp. For sorting, the logs are considered using an adjusted-to-UTC timestamp.

Therefore, in F-Spot, I agree that the user should be able to set the timezone of the camera and the timezone of the pictures. If they don't match, F-Spot should convert the camera's timestamp into the proper timestamp for the picture's locale and store that (including timezone). Sorting could be done with adjusted-to-UTC timestamps.

If a developer could confirm this is the proper strategy, I'll look at making a patch.

The XMP specification[1] states that a datetime object[2] can look like this

   Complete date plus hours, minutes and seconds:
      YYYY-MM-DDThh:mm:ssTZD (eg 1997-07-16T19:20:30+01:00)

This means that in XMP we can use timezone information.
But we can not use timezone data in the EXIF fields.

Therefore I would suggest the following.

1) Store the local time the photo was taken in the EXIF fields (or do not touch it perhaps)
2) Add Original/Modified timestamps to the XMP fields, and here include timezone information.

To create the timezone, I would suggest asking for 
a) the timezone where the photo was taken
b) the timezone the camera was set to

Comments on this?

[1] http://www.aiim.org/documents/standards/xmpspecification.pdf#search=%22exif%20xmp%20timezone%22
[2] http://www.w3.org/TR/NOTE-datetime 

Sounds good to me.

would be nice!

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

I have my camera set to "local time". Now I took a picture and imported it into f-spot. I took the picture at, let's say, 12:00. f-spot now shows 11:00 as the time the picture was taken. I'm still in the same timezone.

I do not think, that this is correct behaviour. I'd prefer it more, if f-spot would simply read the exif time from the picture (12:00) and display that time.

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

Created attachment 107860 [details] [review]
Imports photos without converting date to UTC

I made a small patch for those of you who just want to import the photos and let the date be whatever it is in the EXIF file (like me).
Just a few changes in the JpegFile/... classes. For me, importing a photo resulted in the same date as the exif date for a jpeg file. :) I did not test it for the other files.
Also, adjusting the time via the "Adjust time" tool works fine for me.

Note that this is only a workaround, not a final patch.

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

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

I have experienced the same problems.

I agree that a good solution would be to extend the import options with one timezone for the camera, and one timezone in which the photos were shot.

As far as I can see, the situation is a little different for images with no EXIF header:

Apparently, the time stamp from the filesystem is used instead in this case. Using the filesystem time when the EXIF is missing may indicate that the time information is inaccurate, but I still think that this case should be considered as well.

As far as I know, f-spot should be allowed to assume that the filesystem time is UTC[*], and so any option for altering a time based on the filesystem timestamp should have UTC as default.

[*] As far as I know, the timezone environment variable only changes how a time is displayed, not its actual storage, which is always supposed to be UTC.

Btw, since the problem is that f-spot converts the EXIF time to UTC, a work-around for the problematic EXIF modification is to use f-spot with the TZ set to UTC, e.g.
sh -c 'export TZ=UTC;exec f-spot'
 - but for my 8000 already-imported photos, I will need to repair the EXIF time and I am not sure I would like to rely on the current version of f-spot to do that...

More duplicates: 332025, 340899, 454082.

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

Tip to recover date/time broken by f-spot:

1. Remove photos from f-spot, exit it.
2. Use exiftool to recover: 
   $ exiftool "-CreateDate>DateTimeOriginal" *.jpg
3. Restart f-spot with TZ=UTC (as suggested by Lars Kr. Lundin), and re-import photos.

Is there way to automate import many photos? Is there any command-line interface to f-spot for importing photos? 

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

almost three years... and no resolution... 
hmmm... not even a temporary one (for instance just keep the cameras time, and not do anything)... hmmm...

Maybe a script to fix the database but leave the image file alone? three years and 20-some comments seems to confirm it.

i still can't see why the DateTimeOriginal has to be converted to ANYTHING

whatever time zone you are in, when you press the shutter is the time you want recorded - assuming you have adjusted the camera Date/Time for that particular time zone

let's assume that you HAVEN'T changed the Date/Time from when you started the journey and you've taken photos in three different time zones before you realize the error... isn't it better to make the required Date/Time adjustments yourself , when it suits you, than let f-spot make make an uninformed  decision for you?

I tried to summarize the discussion that happened in this bug report. As far as I can see, two solutions become apparent:

1. Simple: Leave the time as it is in exif

2. Flexible: User chooses "Camera timezone" and "Picture timezone" during import


Pro Simple:
- Easy for the user in the frontend (Gnome's "keep it simple")
- Conversion to UTC is not necessary any more
- Local time is important time for seeing when a picture was taken

Pro Flexible:
- Sorting photos is no problem, see comment 5 and comment 6
- Some users set camera timezone to UTC
- User is reminded to check whether camera was set to correct timezone
- Adding GPS information (UTC timestamp) is easier


Cons apply vice versa. With the addition that flexible would require more code rewrite work (including: changing the "Change time" dialog - how do I change the timezone if I set it wrong during import; how to store utc and local time? like in comment 6 ?)

I hope this discussion finally leads to a solution that is acceptable for everyone, as this bug is one of the most annoying ones IMHO...

Please could reporter update version to (at least) f-spot-0.5.0.3, please.

There has been some mailing list discussion on this subject in the past:
http://mail.gnome.org/archives/f-spot-list/2008-May/msg00061.html
http://mail.gnome.org/archives/f-spot-list/2008-April/msg00047.html

I think the issue is that completely solving the timezone problem is hard, as discussed in this bug and in the mailing list comments above. So while it's a known problem, it's not trivial to solve. 

But meanwhile the current behaviour - which was looks like a first attempt at solving the timezone problem - will fail in a significant number of use cases, and in my view is a data corruption bug.

Personally, I'd agree that not messing with the EXIF time is greatly preferred over the current behaviour, because at least it's predictable. Without a log of when a photo was imported and modified the current behaviour isn't even reliably reversible.

I guess the developers must always use their camera in the same tz as their PC and import their photos every day. There also seems to be an assumption that users never change the clock on their camera.

Personally, most of my photos are taken when I travel. I frequently cross timezones in a single trip (easy enough, just cross the channel), and both my cameras (a Pentax and a Nikon) have a "world time" feature to easily set the correct local time. If I look at the camera whilst travelling, I want to see the correct local time on the screen. If I import a week or two of photos into F-Spot during and after a trip, well, my timestamps get messed up. For extra fun, my last trip spanned the US and EU switches to DST (on different dates).

It wouldn't be quite so bad if F-Spot limited its (wrong) guesses to its own db, but that the default behaviour is to re-write the time in the photo EXIF...

I can't see how the current behaviour is preferable to not messing with the EXIF tags at all.

I can see what the current algorithm was trying to solve, but it fails in so many cases I think it's doing more harm than good.

It's also somewhat shocking that this hasn't received more prompt attention as a data corruption issue - it's not necessarily a problem (all their imported timestamps being messed about with) a user will notice until some time later, when it might really matter to them...

I made a similar patch, but allowing UTC time assumption, if someone really wants to, setting a gconf (pardon, $PreferenceBackend) value:

METADATA_ASSUME_UTC = APP_FSPOT + "metadata/assume_utc";

See http://gitorious.org/~paulwb/f-spot/paulwbs-clone/commits/ImportTimeHandling

I changed it again. Different approach: Don't let f-spot change any dates, just take the dates which are in the file. All other time and time zone handling stuff can be build later on top of it.

My branch doesn't work right yet. The dates are converted once to UTC still. I have to search where this is happening.

After testing it a bit more I can say that yes, it works. Including the Date Adjustment Dialog. The explicit Date is taken by F-Spot, no strange Time Offsets and time zone conversion. (It seems I tested another branch at home, when I wrote the comment above)

Paul's patch seems sensible and an improvement on current behaviour. Thank you.

Further mailing list discussion of the discussion:
http://mail.gnome.org/archives/f-spot-list/2009-June/msg00016.html
http://mail.gnome.org/archives/f-spot-list/2009-August/msg00000.html

Again, the balance of opinion seems to be for the patch (or at least that the current implementation is broken).

re: the method in comment #19 for fixing up the database: is there a way to keep tags etc. across the export and re-import? (Or would it be better to wait and hope for a plugin to fix the dates within f-spot, as Paul suggested on the mailing list?)

Any word on whether Paul's patch will be accepted and applied? The best behavior for F-Spot is to not change _any_ EXIF values unless the users explicitly requests it.

I can confirm that EXIF date fields are still being changed in the version of F-Spot that comes with Ubuntu 9.10 (0.6.1.3).

This is a critical issue which totally prevents me and many others from using F-Spot.

BTW: Why is the status of this bug still listed as UNCONFIRMED? It is obviously confirmed. It is also obviously a critical bug that needs to be fixed.

Could somebody summarize exactly what f-spot is changing in the photos and what change it is making so that I can go and fix what it has done, OOB?

My understanding is that f-spot is "normalizing" some (which?) date field in the photo file to UTC.  That is, it is applying the offset of the timezone in which the photos are imported to the timestamp in the photo file.  Is that all it's doing?  Or am I completely wrong here?

Which field is being modified?

I guess before I re-invent a wheel, does anyone have a script that restores the data to it's original value?

And while I am asking, what is the timestamp that f-spot is showing on the bottom left when I select a photo?  Is that supposed to be UTC or local time?  Or something else?

Here's a screenshot showing the two datetime fields I know that F-Spot is changing:
http://daniel-bartholomew.com/wordpress/wp-content/uploads/2009/10/gnome-thumb-screenshot.png

There are three datetime fields: DateTime, DateTimeOriginal, and DateTimeDigitized. Of the three, the only one that F-Spot left alone (in my testing) was DateTimeDigitized. In the case of this photo, prior to import into F-Spot all three of these fields were identical.

F-Spot changed the DateTime field to the datetime when I imported the photo to F-Spot. This isn't helpful at all because it is meaningless to everyone and everything except F-Spot itself. F-Spot should track this internally and not write it to the EXIF meta-data of the photo.

F-Spot changed the DateTimeOriginal to what it thinks is UTC. F-Spot should leave this field alone. It could offer to change it to UTC, but it should get the user's OK before doing it.

All three of the DateTime fields should have the same values after the import that they had before the import.

F-Spot is overwriting at least the DateTimeOriginal EXIF field on all imported photos with a time calculated by assuming DateTimeOriginal is in the computer's time zone and converting this to UTC time.

For example, my computer is in San Diego, CA (UTC -8).  I took a photo in San Diego on July 4, 2008 at 20:04:37 (camera was set to local time).  Upon import to F-Spot, this date was overwritten with July 5, 2008 04:04:37.  This would happen no matter where the original photo was taken.  Pictures taken in Chicago and New York (with the camera always set to local time) would also have their times overwritten with times 8 hours in the future because I imported the pictures with F-Spot installed on a computer in the Pacific time zone.

Step 2 of Lev Nezhdanov's fix (comment 19 above), fixes the corrupted EXIF time by copying the file creation date to the DateTimeOriginal field.

See here, too: http://mail.gnome.org/archives/f-spot-list/2009-June/msg00016.html

Depending on the DST settings, the time is shifted wrong so that even the time f-spot assumes as UTC is not UTC.

First, I have to comment on the DateTime-fields. There are three such fields
defined by the Exif specification (http://exif.org/specifications.html). A look
at the specification tells us the following for the DateTime-field (without
"Digitzed" or "Original"):

DateTime: "In this standard it is the date and time the file was changed"

This simply means, that this field should be updated, when the file is changed.
And if a file is changed with e.g. Gimp, this field is also updated. Without
having a look at the code I would blame libexif for following the specification
in this case. So there is no need to keep all three fields in sync, even if
some users expect this.


However, this is no reason for justify the wrong time handling. But again, it
will be fixed.

(In reply to comment #31)
> 
> And while I am asking, what is the timestamp that f-spot is showing on the
> bottom left when I select a photo?  Is that supposed to be UTC or local time? 
> Or something else?

To answer my own question, it would appear that this displayed time is UTC.  ~sigh~  That at least should be adjusting the "normalized-for-UTC" value back to local time for display purposes, no?

At least then I could easily deal with the "camera was not set for local timezone" issue easily enough, independent of the f-spot-mangling-exif-data issue without having to do the math between local timzone, utc and the picture location timezone.  I guess that's a new/different bug than this though.

(In reply to comment #35)
> First, I have to comment on the DateTime-fields. There are three such fields
> defined by the Exif specification (http://exif.org/specifications.html). A look
> at the specification tells us the following for the DateTime-field (without
> "Digitzed" or "Original"):
> 
> DateTime: "In this standard it is the date and time the file was changed"
> 
> This simply means, that this field should be updated, when the file is changed.
> And if a file is changed with e.g. Gimp, this field is also updated. Without
> having a look at the code I would blame libexif for following the
> specification in this case. 

If libexif is changing DateTime on import then it is interpreting the standard wrong.

Importing a photo into F-Spot (or any other image organizer) should not change the photo. Users expect the photo they import to be the same photo it was prior to import. This includes EXIF data. The DateTime field should not be changed simply because the photo was imported into F-Spot and a sha1sum of the file should be identical both before and immediately after import, if it is different then F-Spot can't be trusted with users' photos.

If the user tweaks a photo (by cropping, enhancing, editing, etc...) then the field should of course be updated, but not before.

> So there is no need to keep all three fields in sync, even if
> some users expect this.

But there is a need for F-Spot to not change things that don't need to be changed.

> However, this is no reason for justify the wrong time handling. But again, it
> will be fixed.

Good. :)

The main thing is that f-spot is, at bottom, a database.  It is a program that creates an easily searchable list of photographs and their attributes to make organizing them easier.  There is no reason to change the photograph files unless the user specifically invokes an action that alter the photograph (crop, red eye removal, adjust time, etc.).  A search engine does not edit the web pages it indexes, nor should a photo management program edit the information in those photos.

I have an old-school folder structure with photos and wanted to test a couple of different photo managers. I found out that I expected the photo manager not to change the photos. There was no warning, but my files were changed. This makes the testing of different "managers" (compared to editors) a dangerous business as I thought that importing pictures without copying them would render the source unchanged. It wasn't! At least one should have a warning - atm. F-Spot is not just useless, but data corrupting.

This bug is critical - a show stopper. The fact that for 4 years different people has contributed to this bug report makes it evident.

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

Status:  	UNCONFIRMED 

I know we all have things to do and developers focus on whatever they think is important (and that is fine), but... still unconfirmed? seriously? IF you have time to mark as duplicates, please, change this status.

Please could this bug be fixed?  It really doesn't make much sense keeping this behavior, and if it IS to be kept, could there be an option in the interface to turn it on first? 

I can't see many scenarios when people would want the *very useful* date data to be removed from photos without asking first.  Plugging my iphone in is enough to remove the data on Ubuntu, which is rather annoying to say the least.

Bumping the priority of this bug. Sorry everyone that this isn't fixed yet. It's a difficult problem though, partly caused by the broken datetime storage in EXIF.

I'll start poking the right people to get this fixed. Considering it a blocker for the next major release now.

If you want to help out with this, part of the solution is switching our metadata handling to Taglib#, which needs improved testing and file type support. More info about it here: http://gitorious.org/taglib-sharp

So this is one of our most controversial issues to date and to be honest: I'm sick of it.

In the long run we need to come up with a proper solution that suits both the "local time"-photographer and the "UTC all the time"-photographer. For now, it seems that the average user does local time. We also have the time adjustment dialog to adjust stuff for those who disagree.

So, I've committed part of Paul's patch. By default, F-Spot will not convert timestamps. I fully agree that we should not do this.

Those who do want this can submit something for this. I'm thinking along the lines of an extension that adds an option to the import window. I don't want an option for this in the import window all the time: most users don't care.

In the long run, we should reconsider how we handle and store timestamps. I know Mike Gemuënde has spent some time on this already in the context of the photo support in Taglib#. We should switch to that in the near future. For now, this fix is a decent workaround.

In summary: yes, your timestamps are now safe. Go cheer on twitter.

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