Bug 315740 - Date is incorrectly completed to day in future
Summary: Date is incorrectly completed to day in future
Alias: None
Product: digikam
Classification: Applications
Component: Searches-Dates (show other bugs)
Version: 4.3.0
Platform: openSUSE Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Digikam Developers
Depends on:
Reported: 2013-02-25 07:04 UTC by Gerard Dirkse
Modified: 2016-05-10 16:33 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.0.0


Note You need to log in before you can comment on or make changes to this bug.
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.

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

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

Can you reproduce the problem with current implementation ?

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

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.

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.
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

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