After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 306945 - Two Digit Years Are Converted Unconditionally to 20XX
Two Digit Years Are Converted Unconditionally to 20XX
Status: RESOLVED DUPLICATE of bug 339813
Product: evolution
Classification: Applications
Component: Contacts
2.2.x (obsolete)
Other other
: Normal normal
: ---
Assigned To: Devashish Sharma
Evolution QA team
: 491842 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-06-08 20:24 UTC by Charles P. Wright
Modified: 2008-03-14 17:14 UTC
See Also:
GNOME target: ---
GNOME version: 2.7/2.8


Description Charles P. Wright 2005-06-08 20:24:34 UTC 
Distribution: Red Hat Enterprise Linux AS release 4 (Nahant Update 1)
Package: Evolution
Severity: normal
Version: GNOME2.8.0 unspecified
Gnome-Distributor: Red Hat, Inc
Synopsis: Two Digit Years Are Converted Unconditionally to 20XX
Bugzilla-Product: Evolution
Bugzilla-Component: Contacts [was: Addressbook]
Bugzilla-Version: unspecified
Description:
Description of Problem:
If you enter a date like "1/1/77" into the birthday field is converted
to 1/1/2077.  There should be some pivot point (e.g., now), for this
date input so that two digit years go backwards if they are greater than
the current year.  For other boxes, some logical default like 10 years
into the future could be used.




------- Bug moved to this database by unknown@bugzilla.gnome.org 2005-06-08 20:24 UTC -------
Comment 1 André Klapper 2005-06-08 23:36:27 UTC 
correct, confirming.
it's the same in the appointment editor, by the way (but perhaps it makes sense 
to only set appointments in the future ;-)
Comment 2 Max Wiehle 2005-10-24 11:56:26 UTC 
The string to date/time conversion happens in 
evolution/e-util/e-time-utils.[ch]

ETimeParseStatus
e_time_parse_date (const char *value, struct tm *result)

This file uses the current century if only 2 digits have been used. Quite a
reasonable decision if it's used both for birthdays as well as appointments.
Maybe a parameter could be introduced to seperate for future or past. An int to
specify the offset might be possible as well.

I'll see where this funktion is being used and then i might write a patch...
Comment 3 Poornima 2006-04-27 08:57:02 UTC 
*** Bug 339813 has been marked as a duplicate of this bug. ***
Comment 4 Øystein Gisnås 2007-04-23 21:09:56 UTC 
There are a couple of possible solutions to this.

I notice that locales with four-digit years don't have this problem. An attractive solution would be to force four-digit years for all locales. No idea if that's possible to do, though.

A likely more feasible solution is to add an extra flag for dates in the past to e_time_parse_date as Max sketches. The add century conditional could be skipped then. Suboptimal and will break abi, but in my opinion, the most feasible.
Comment 5 Ross Burton 2007-10-30 20:18:25 UTC 
*** Bug 491842 has been marked as a duplicate of this bug. ***
Comment 6 Patrick Hulin 2007-12-09 13:36:46 UTC 
Oystein, what about a separate function which adds this sort of pivot point to e_time_parse_date? That way you at least wouldn't break abi...
Comment 7 Milan Crha 2008-03-14 17:14:30 UTC 
This has been fixed there already.

*** This bug has been marked as a duplicate of 339813 ***