Bug 315740

Summary: Date is incorrectly completed to day in future
Product: [Applications] digikam Reporter: Gerard Dirkse <gerard.dirkse>
Component: Searches-DatesAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: caulier.gilles, metzpinguin, smit.meh
Priority: NOR    
Version: 4.3.0   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: http://commits.kde.org/digikam/c1af0146604723fe9e3c8419a96392af25b418e6 Version Fixed In: 5.0.0

Description Gerard Dirkse 2013-02-25 07:04:34 UTC 
When changing the creation date of a picture in the date field of the caption/tags panel (in my case format is dd/mm/yy and the change of yy is greater then current year (13) date is completed to 20yy, so creationdate ends up in the future.

Reproducible: Always

Steps to Reproduce:
1.  Select a picture
2. In caption/tags pane, change yy in Date to 98

Actual Results:  
Picture will have date dd/mm/2098

Expected Results:  
Picture should have date dd/mm/1998

Problem can be circumvented by changing yy to desired yyyy (include century), whic is a nuisance for the 100's of photos I am digitising.
Comment 1 Smit Mehta 2013-02-25 13:40:03 UTC 
Hi Gerard

I confirm the bug. I will have a look into it. Thanks for sharing the problem with us.

Smit
Comment 2 caulier.gilles 2014-09-05 07:21:36 UTC 
Gerard,

This file still valid using last digiKam 4.2.0 ?

Gilles Caulier
Comment 3 Gerard Dirkse 2014-09-06 01:26:13 UTC 
(In reply to Gilles Caulier from comment #2)
> Gerard,
> 
> This file still valid using last digiKam 4.2.0 ?
> 
> Gilles Caulier

I will try as soon as I am back from holiday and started working the photos again.
Comment 4 Gerard Dirkse 2014-09-19 14:29:51 UTC 
Just tested this problem on opensuse digikam 4.3.
Comment 5 Gerard Dirkse 2014-09-19 14:33:14 UTC 
and it is still there, when changing date (in date field of pane not using calender view) to 01/01/99 date of pic will be 01/01/2099 and not 1999 as expected.
Comment 6 caulier.gilles 2015-05-10 16:46:05 UTC 
Maik, 

Can you reproduce the problem with current implementation ?

Gilles
Comment 7 Maik Qualmann 2015-05-11 19:35:17 UTC 
Gilles,

Yes, I can reproduce the problem. I think it's normal behavior at 2 digit entry. An image date in the future might make no sense. It could be a if (year > current year) year - = 100 perform.

Maik
Comment 8 caulier.gilles 2015-05-11 19:50:15 UTC 
a If with this condition with a messagebox to indicate an error will be fine.
Gilles
Comment 9 Maik Qualmann 2016-05-10 04:27:13 UTC 
Git commit c1af0146604723fe9e3c8419a96392af25b418e6 by Maik Qualmann.
Committed on 10/05/2016 at 04:24.
Pushed by mqualmann into branch 'master'.

use 4-digit year and seconds in the description tab
Related: bug 362441
FIXED-IN: 5.0.0

M  +91   -79   app/date/ddateedit.cpp
M  +2    -0    app/date/ddatetimeedit.cpp

http://commits.kde.org/digikam/c1af0146604723fe9e3c8419a96392af25b418e6
Comment 10 Maik Qualmann 2016-05-10 16:33:33 UTC 
Git commit d646b10926c373e4afd1ca217be96ce4972d52dc by Maik Qualmann.
Committed on 10/05/2016 at 16:32.
Pushed by mqualmann into branch 'master'.

use always 4-digit year and seconds in Metadata Editor
Related: bug 362441

M  +23   -0    utilities/metadataedit/exif/exifdatetime.cpp
M  +14   -0    utilities/metadataedit/iptc/iptcenvelope.cpp
M  +19   -0    utilities/metadataedit/iptc/iptcorigin.cpp
M  +18   -0    utilities/metadataedit/iptc/iptcproperties.cpp
M  +19   -0    utilities/metadataedit/xmp/xmporigin.cpp

http://commits.kde.org/digikam/d646b10926c373e4afd1ca217be96ce4972d52dc