Bug 159817 - kphotoalbum sets the wrong date in exif header when editing it manually
Summary: kphotoalbum sets the wrong date in exif header when editing it manually
Alias: None
Product: kphotoalbum
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal with 20 votes (vote)
Target Milestone: ---
Assignee: KPhotoAlbum Bugs
Depends on:
Reported: 2008-03-25 09:19 UTC by Tobias Leupold
Modified: 2010-02-16 01:33 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Leupold 2008-03-25 09:19:03 UTC
Version:           3.1.1 (using KDE 3.5.8)
Installed from:    Gentoo Packages
Compiler:          4.1.2 
OS:                Linux

When I edit the time when an image was created in kphotoalbum (to correct it or to e. g. add the real creation time to a scanned image), only the year is saved correctly, the month is set to 1 and the day also to 1.

I don't know if this is a kphotoalbum issue or a problem of the underlying exif libs, as the eixftime program behaves in the same wrong way:

tobias@schleppi Ali $ exiftime -t a -v 2005y -v 5m -v 5d 01.jpg 
Image Created: 2005:05:05 01:00:00 
Image Generated: 2004:05:05 01:00:00 
Image Digitized: 2004:05:05 01:00:00 
tobias@schleppi Ali $ exiftime 01.jpg 
Image Created: 2005:01:01 00:00:00

However, this is a quite annoying bug if one wants to get all images in the right order and one has to fix some dates.
Comment 1 Jan Kundrát 2008-03-25 10:11:37 UTC
What's the order that you have in the Settings->KPhotoAlbum->Metadata->Date->Fileds to write value to?
Comment 2 Tobias Leupold 2008-03-25 18:55:14 UTC
I never changed anything there; the order should be still set to the defaults. Here is it:

-- stop --
Comment 3 Tobias Leupold 2008-03-25 19:24:56 UTC
Just to mention it: with exiv2, it is possible to set the dates correctly here, e. g.:

exiv2 -M"set Exif.Image.DateTime Ascii '2006:05:25 00:00:00'" 01.jpg
Comment 4 Jan Kundrát 2008-03-25 23:40:27 UTC
What happens if you run kphotoalbum like this: `LC_ALL=C KDE_LANG=en_US kphotoalbum`? Does it work?
Comment 5 Jan Kundrát 2008-03-25 23:45:53 UTC
Actually I got your report wrong. What's broken here, adjusting the image date in KPhotoAlbum (ie. changes made in the Annotation Dialog) or exporting it back to the EXIF (Maintenance -> Write metadata)? If the former, then this is a duplicate of bug 140030.
Comment 6 Tobias Leupold 2008-03-26 12:25:21 UTC
Wrinting the changes to the files didn't work.

Aditionally, sometimes, kphotoalbum behaves strange with the dates of the photos: when sorting all images by date, some images still go wrong after having set the dates correctly, and the month and day are set to "1", although the EXIF headers contain the right date. Reading the date out of the EXIF header again sets the date correctly again.
But I didn't manage to reproduce this behaviour somehow ... it just happens from time to time.
Comment 7 Silent Warrior 2009-04-10 12:35:27 UTC
Hey guys,

I managed to reproduce the bug:

It happens to photos with a date in March, May, October or December.
Whenever you select the category-editor for such a photo and cancel the dialog, it will ask you to lose the entered data (although nothing was changed).
When instead of canceling the category editor you confirm the changes, the date of the photo is changed to 1. January of the same year. (You will see it if you open the dialog again.)
There is no way to get the date back to March, May,... because the dialog does not seem to accept these months.

Using the command line above `LC_ALL=C KDE_LANG=en_US kphotoalbum` solves the problem: the dates are no longer changed...
Nevertheless i think this should be fixed, because at first you won't realize that photos are misplaced.

Best regards,
Comment 8 Silent Warrior 2009-04-10 13:05:09 UTC
i guess it is the different typing in english and german:
Jan = Jan; Feb = Feb,....

Mar != Mär
Mai != May
Okt != Oct
Dez != Dec
Comment 9 Tobias Leupold 2009-08-31 02:20:30 UTC
Is anybody working on this? I'm pretty sure that "Silent Warrior" exactly describes the problem. Would be cool if this issue would be fixed :-)
Comment 10 Tobias Leupold 2009-12-20 21:10:09 UTC
Won't at least anybody remove the "unconfirmed" state from this bug?
Comment 11 Miika Turkia 2010-01-06 07:40:00 UTC
I think you are talking about action that is done with KIPI plugins (found under the Plugins menu). They are external plugins and part of a different project http://www.kipi-plugins.org/. If this is the case you should report the bug to kipiplugins in bugzilla.
Comment 12 Tobias Leupold 2010-01-06 12:24:08 UTC
No, the bug did not happen when using some plugins but the normal "Annotate" dialog.
Comment 13 Miika Turkia 2010-01-06 17:46:54 UTC
Seems to be working on kphotoalbum 4.1.1 and Ubuntu 9.10. (If I did the described steps correctly.)
Comment 14 Jan Kundrát 2010-02-16 01:33:46 UTC
Hi Tobias, sorry for not responding earlier. As I can't reproduce this issue on my box (I'm using Czech and English locales and trying to run KPA as `LC_ALL=de_DE.utf8 KDE_LANG=de_DE kphotoalbum -demo`), I'll close this report now -- I recall some patches going to that area of KPA.

Tobias and/or Silent Warrior, please open this bug if the problem still persists (although I hope it is *really* fixed, even for you).