GNOME Bugzilla – Bug 454082
Import dialog modifies Exif.Photo.DateTimeOriginal of jpeg
Last modified: 2010-03-23 14:00:01 UTC
Please describe the problem: f-spot's import dialog when importing from a directory adjusts the Exif.Photo.DateTimeOriginal timestamp to 2 hours earlier, corrupting the correct timestamp. This happens even when the import is canceled. Steps to reproduce: 1. start the import dialog (Ctrl-N) 2. select a directory with some new jpeg-images in it; the thumbnails show up in the dialog 3. press Cancel (or Import). Actual results: The Exif.Photo.DateTimeOriginal is put back by 2 hours (I suspect that this is some heuristic to convert to UT or GMT). The incorrect timestamp is also shown in the information panel in the bottom-left corner of f-spot's main window when the image is selected. Expected results: The Exif.Photo.DateTimeOriginal timestamp shouldn't be modified at all during import, but only when the program is explicitly instructed to do so (via the Adjust Time option in the Edit menu). Does this happen every time? Yes, it is repeatable. Other information: Before the import dialog a issued the following command: $ exiv2 -pt img_2277.jpg | grep DateTime Exif.Image.DateTime Ascii 20 2007:07:05 21:12:18 Exif.Photo.DateTimeOriginal Ascii 20 2007:07:04 18:43:18 Exif.Photo.DateTimeDigitized Ascii 20 2007:07:04 18:43:18 Immediately after pressing 'Cancel': $ exiv2 -pt img_2277.jpg | grep DateTime Exif.Image.DateTime Ascii 20 2007:07:05 21:12:18 Exif.Photo.DateTimeOriginal Ascii 20 2007:07:04 16:43:18 Exif.Photo.DateTimeDigitized Ascii 20 2007:07:04 18:43:18
you're located in Western Europe, right ? (or in the same timezone ...)
> you're located in Western Europe, right ? Yes, on my computer TZ=Europe/Amsterdam, at the moment time difference with UT = +0200 (Middle European Summer Time). My camera's clock is set to local time, which is the same as my watch.
I've got the same problem with version 0.4.3.1 Given that this is corrupting image data and no visible progress has been made in almost a year, can this at least be given some priority instead of being listed as unconfirmed?
Severity of this should be set to 'Critical' since it causes loss of data.
Version 0.5.0.3 still suffers this unexpected behavior. I would also set this bug to 'CRITICAL'. Stephane, you said on the mailing-list, that you would fix it. Is it already fixed somewhere? I mean, a newer version, the SVN repository or something like that. Or are you working on it?
I can as well confirm this problem on F-Spot 0.5.0.3 (Ubuntu 9.04 package). It has been nearly two years now since this bug was filed. Can you please update this issue with a status information? Is someone working on it? What is the expected fix date? Also, I support the previous posters that the severity of this issue should be increased to at least 'MAJOR'. (EXIF's "DateTimeDigitized" still holds the camera's actual date/time information. While this can somehow be used to manually fix the date/time after having imported the images, at the moment we lose the correct data from a user's point of view. Not only in F-Spot, but also when using the JPG-files in other common programs subsequently.)
Still happens in 6.0.0
This is probably a duplicate of bug #340903 ?
(In reply to comment #8) > This is probably a duplicate of bug #340903 ? I think it is.
*** Bug 593002 has been marked as a duplicate of this bug. ***
Please mark this bug as a duplicate of bug #340903 as both bugs share the same problem: F-Spot is changing EXIF date tags without being asked to and without telling anyone. Both are big no-nos. F-Spot should never change an EXIF date tag on its own. The user should specifically request any changes to be made and only then should F-Spot be allowed to change the EXIF tags and it should only change the tag it has been asked to change.
*** This bug has been marked as a duplicate of bug 340903 ***