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 339813 - Birthday field useless for old people
Birthday field useless for old people
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Contacts
2.22.x (obsolete)
Other Linux
: Normal blocker
: ---
Assigned To: evolution-addressbook-maintainers
Evolution QA team
: 306945 346747 351556 352184 352787 386668 406367 417938 486375 488543 489352 491153 493733 495486 499188 499293 506411 506627 506637 506832 507466 507602 510416 511198 515782 515869 516909 517042 518129 518490 518499 519967 523431 523829 524448 524677 527693 529894 530168 (view as bug list)
Depends on:
Blocks: 352187
 
 
Reported: 2006-04-26 14:46 UTC by Ross Burton
Modified: 2013-09-13 00:57 UTC
See Also:
GNOME target: 2.22.x
GNOME version: ---


Attachments
Screenshot (10.51 KB, image/png)
2006-04-26 14:48 UTC, Ross Burton
  Details
proposed evo patch (5.95 KB, patch)
2007-06-21 17:04 UTC, Milan Crha
committed Details | Review
proposed eds patch (9.07 KB, patch)
2007-06-21 17:08 UTC, Milan Crha
committed Details | Review
Patch to display birthday ages correctly in calendar (763 bytes, patch)
2007-10-21 10:52 UTC, Peter Lord
committed Details | Review
screenshot of Evo Calendar incorrectly calculating ages (664.10 KB, image/png)
2007-11-11 16:44 UTC, Simon Hepburn
  Details

Description Ross Burton 2006-04-26 14:46:06 UTC
I cannot use the Evolution Birthday field to enter the birthdates of my parents, yet along my grandparents.  For some reason the date field is using two digit years (en_GB, if it makes a difference): if I enter 1/1/69 and press the dropdown the calendar shows 1969.  However, if I enter 1/1/68 and press the dropdown it shows 2068.

Obviously this is very very wrong.
Comment 1 Ross Burton 2006-04-26 14:48:18 UTC
Created attachment 64327 [details]
Screenshot

Proof.
Comment 2 Ross Burton 2006-04-26 14:58:45 UTC
Richard Hult just attempted to replicate this in sv_SE, and his date format is yyyy-mm-dd.  This is looking a lot like a en_GB bug...
Comment 3 Dominic Lachowicz 2006-04-26 15:17:12 UTC
Is evolution just using something like strftime(3)'s "%x" argument to format the date?

       %x     The  preferred  date representation for the current
              locale without the time.
Comment 4 Germán Poo-Caamaño 2006-04-26 15:21:59 UTC
I can also confirm this bug for en_US.
Comment 5 Thomas Thurman 2006-04-26 15:24:31 UTC
I can confirm this bug for cy_GB.
Comment 6 André Klapper 2006-04-26 18:48:56 UTC
could be related or even a duplicate of bug 306945
Comment 7 Morten Welinder 2006-04-26 19:22:54 UTC
Dupe.  The problem is how the string "1/1/68" is interpreted when
entered.

On top of that it is probably never a good idea to display two-digit
years.
Comment 8 Eduardo Pérez Ureta 2006-04-26 19:43:16 UTC
Always use ISO 8601 or time_t internally, but never a braindead date/time format like the American or European ones.
This bug should be solved by just having the textfield convert the date to the stupid date format only for viewing but never store it internally.
I'm sure this is the way you are going to fix it. I'm posting here just in case.
Comment 9 Poornima 2006-04-27 08:57:02 UTC
I am not able to replicate issue of 1/1/68 in evolution 2.6.0, so difference in 1/1/68 and 1/1/69 should be resolved in evolution 2.6.0 is used. For the rest of the issue this bug is duplicate if bug 306945. If reporter is not convinced reopen this bug.

*** This bug has been marked as a duplicate of 306945 ***
Comment 10 Ross Burton 2006-04-27 09:08:54 UTC
I'm using Evolution 2.6.1...
Comment 11 Germán Poo-Caamaño 2006-04-27 13:26:04 UTC
I'm alsousing Evolution 2.6.1 and I can reproduce it using en_US
Comment 12 André Klapper 2006-04-27 14:47:18 UTC
poornima, as long as you do not provide information which locale you use, a "WORKSFORME" is pretty useless.
Comment 13 Bart de Koning 2006-06-06 07:09:51 UTC
I can also reproduce it using 2.6.1 and locale nl_NL
Comment 14 Poornima 2006-06-29 09:20:15 UTC
I am using en_US locale. If i type 1/1/69 and then click on drop down calendar it shows 2069 as well as if 1/1/68 is typed and then click on drop down calendar it shows 2068. Verified in both 2.6.2 as well as head build 2.7.3.
Comment 15 André Klapper 2006-07-06 17:26:32 UTC
*** Bug 346747 has been marked as a duplicate of this bug. ***
Comment 16 Sebastien Bacher 2006-08-02 14:39:57 UTC
Ubuntu bug about that: https://launchpad.net/distros/ubuntu/+source/evolution/+bug/48679

"Birthdays before 1969 shows as birthdays in the future 2000+

Ubuntu Dapper final release

For example I put the date: 23/06/29 for my grandma and it shows up as 2029 instead of 1929 ..."
Comment 17 André Klapper 2006-08-17 19:43:18 UTC
*** Bug 351556 has been marked as a duplicate of this bug. ***
Comment 18 Poornima 2006-08-21 06:18:56 UTC
*** Bug 352184 has been marked as a duplicate of this bug. ***
Comment 19 André Klapper 2006-08-26 12:26:21 UTC
*** Bug 352787 has been marked as a duplicate of this bug. ***
Comment 20 Jordi Mallach 2006-09-13 21:17:11 UTC
Confirmed with ca_ES as well; evo 2.6.3.
Comment 21 Guillermo Gutiérrez Herrera 2006-10-13 22:42:52 UTC
I can confirm this bug with es_ES and Evolution 2.8.1 (ubuntu edgy)
Comment 22 Tom Billiet 2007-01-27 17:14:49 UTC
I can also confirm this in evolution 2.8.2
btw: http://bugzilla.gnome.org/show_bug.cgi?id=386668 seems to be a dupe
Comment 23 Ross Burton 2007-01-27 17:21:36 UTC
*** Bug 386668 has been marked as a duplicate of this bug. ***
Comment 24 Nathan Owens 2007-02-04 00:11:58 UTC
I just tried it out and it's not a "true" bug. Here's what happens:
If the user enters something like 8/31/54, then the date will be saved as 8/31/2054. However, if the user enters the date as 8/31/1954, then the date will be saved in the year 1954, as expected.

The easiest fix for this would be to prevent 2-digit years from being entered in the first place.

I believe a better option would be to change the Birthday field to have 3 fields: one for the month, one for the day, and one for the year. Each would be a drop-down (combo) box that would contain the valid values for each field.

I think the second option helps prevent a lot of possible problems from user error. For instance, many Europeans write dates as DD/MM/YYYY, whereas Americans will write dates as MM/DD/YYYY. In any GUI, there should be no ambiguity as to how to enter data. The 3 separate fields would remove the current ambiguity and also make the programming less prone to bugs.
Comment 25 Karl Wagener 2007-02-04 00:26:19 UTC
Nathan:
If you are using US localization then this bug won't affect you.
Comment 26 Nathan Owens 2007-02-04 01:42:11 UTC
Karl: I see what you mean (I am using en_US). Setting the date to 1/1/69 will set the date to 2069 for me, whereas for the original bug reporter (Ross) it sets it to 1969. However, this is still improper - most likely I wanted to set it to 1969. What I'm proposing is preventing 2-digit years from being entered in the first place so there isn't any confusion.

The backend structure EContactDate (which stores the information for the birthday field) has 3 integer members: year, month, day. The GUI widget that edits the date, EDateEdit, also has the same 3 members. Going away from a textual-entry format (which is an interface prone to user-error, software bugs like this, etc.) to a drop-down combo box should fix this problem regardless of locale. The year field would always be a 4-digit year.
Comment 27 Karl Wagener 2007-02-04 02:16:15 UTC
1968 and before is invalid in some locales, that's the bug... but if what you say will fix this in all locales then go for it!
Comment 28 Bart de Koning 2007-02-05 20:18:44 UTC
The funny thing is that using Evolution 2.8.1 and locale nl_NL, you cannot enter a date like 16-08-1949 (shows a message that the date value is incorrect), however you are allowed to enter 16/08/1949. The programme remembers the 1949 correctly until you close the dialogue and open it again. It will show 16-08-49 and pushing the button will show 2049 then. I certainly call that a true bug by the way. Especially because my system ended up in some problems when I entered 16-08-1949. It shows the error message and changes the date to 16-08-19. However if I try to click on the date then to change it again the dialogue hangs or even results in a crash.
For your information F-spot contains a similar problem, when changing the dates of your foto's. Although I never encoutered hanging or crashing dialogues there. 
Comment 29 Markus Nussdorfer 2007-02-10 12:40:28 UTC
*** Bug 406367 has been marked as a duplicate of this bug. ***
Comment 30 Timm 2007-02-14 18:14:19 UTC
Using Evolution 2.8.1 on Ubuntu Edgy, en_US, and the bug is still there.

That is really annoying, and you can not expect people to flick back 50 years using the calendar widget :( (which is even scrolling behind if you click to fast).

4 digit would be really great :)
Comment 31 Markus Nussdorfer 2007-02-14 18:23:53 UTC
(In reply to comment #30)
> Using Evolution 2.8.1 on Ubuntu Edgy, en_US, and the bug is still there.
> 
> That is really annoying, and you can not expect people to flick back 50 years
> using the calendar widget :( (which is even scrolling behind if you click to
> fast).
> 
> 4 digit would be really great :)
> 
I even tried that without any success
Comment 32 Timm 2007-02-14 18:54:00 UTC
(In reply to comment #31)
> (In reply to comment #30)
> > 4 digit would be really great :)
> > 
> I even tried that without any success

Yes, THAT is the whole problem.

Evolution must switch to 4-digit yearnumbers as soon as possible.

Comment 33 André Klapper 2007-03-17 19:52:39 UTC
*** Bug 417938 has been marked as a duplicate of this bug. ***
Comment 34 Alexander “weej” Jones 2007-03-28 20:19:39 UTC
/As if/ we have a Y2K bug in Evolution.
Comment 35 James Brown 2007-05-31 14:34:09 UTC
Still present in 2.10.1 en_US (I know, "me too" syndrome). Particularly annoying, because apparently four-digit years aren't "valid dates".
Comment 36 Alexander “weej” Jones 2007-06-15 23:35:43 UTC
The locale setting depicts an *output formatting* for dates. I don't see how this should have ever been applied to *input parsing*.
Comment 37 André Klapper 2007-06-18 19:32:13 UTC
another option would be to force the use of four digit year numbers by displaying "00.00.0000" instead of the "None" string.
Comment 38 André Klapper 2007-06-18 19:35:43 UTC
(In reply to comment #3)
> Is evolution just using something like strftime(3)'s "%x" argument to format
> the date?

no - see bug 336253.
Comment 39 André Klapper 2007-06-18 19:36:33 UTC
@mcrha: seen bug 306945 comment 4 ?
Comment 40 Milan Crha 2007-06-19 08:51:26 UTC
Andre, right now. There are still too many options, every has its own benefit. Who will do the decision?

From my point of view, you need always touch e-time-utils, either because of forcing 4 digit year or to put parameter for "offset" when user writes 2-digit year. And you also need to touch e-dateedit to reflect these new options.

My suggestion: keep "None" for no date, it is more descriptive to user than such "zeros". Add both "gboolean allow_two_digit_future" to all related date-parsing functions and "gboolean force_4_digits_year" to all related date-formatting functions. There will be many changes in e-time-utils.[ch] and a bit in e-dateedit.[ch]. Default for e-dateedit will be allow_two_digit_future=TRUE and force_4_digits_year=FALSE (both to keep actual behavior), and change this in contact editor to allow_two_digit_future=FALSE and force_4_digits_year=TRUE for birthdays and anniversaries.

That allow_two_digit_future only says what to do after converting from two digit year, if it's in the future (next year or higher), and this option is FALSE, then decrease by 100, otherwise keep as is. I think it's better than "raw" offset, because when one type "05" as year, then it could be better to serve as 2005 than 1905.

(I also could not think about better/shorter names for parameters.)

Maybe, there is better approach.
Comment 41 Milan Crha 2007-06-21 17:04:27 UTC
Created attachment 90405 [details] [review]
proposed evo patch

for evolution;

forces 4-digit year in e-dateedit and in contact-editor, when changing from 2-digit year, then if in the future year, decreased by 100 (to move to last century, not stay in actual).
Comment 42 Milan Crha 2007-06-21 17:08:03 UTC
Created attachment 90406 [details] [review]
proposed eds patch

for evolution-data-server;

changed e-time-utils.h API (added 3 new functions). The third one is system-dependent, e_time_get_d_fmt_with_4digit_year, and needs to be written for Win32 system, at least.
Comment 43 Srinivasa Ragavan 2007-07-06 19:39:52 UTC
CCing chen, as some of the calendar code gets impacted.
Comment 44 André Klapper 2007-10-16 00:07:31 UTC
*** Bug 486375 has been marked as a duplicate of this bug. ***
Comment 45 Peter Lord 2007-10-20 12:07:52 UTC
FYI, I tried these patches based on the source rpm's from opensuse 10.3 ( if it matters ).  All works well, except the age is calculated incorrectly in the calendar item.

ie, I entered by birthday of 30th Jan 1965, and the calendar showed ( on 2008 ):-

Birthday, Lord, Peter (38)

should have been (43) 

Year 1971 shows me at age 1


So I think there is a little more to it than this :-(
Comment 46 Peter Lord 2007-10-21 10:50:36 UTC
(In reply to comment #45)
> FYI, I tried these patches based on the source rpm's from opensuse 10.3 ( if it
> matters ).  All works well, except the age is calculated incorrectly in the
> calendar item.
> 
> ie, I entered by birthday of 30th Jan 1965, and the calendar showed ( on 2008
> ):-
> 
> Birthday, Lord, Peter (38)
> 
> should have been (43) 
> 
> Year 1971 shows me at age 1
> 
> 
> So I think there is a little more to it than this :-(
> 


I think a FIXME in e-cal-backend-contacts.c also needs to be removed so that dates before 1970 are preserved.  

I'm not sure if there are other implications, though.  Patch attached all the same.
Comment 47 Peter Lord 2007-10-21 10:52:51 UTC
Created attachment 97543 [details] [review]
Patch to display birthday ages correctly in calendar
Comment 48 André Klapper 2007-10-23 12:44:32 UTC
*** Bug 489352 has been marked as a duplicate of this bug. ***
Comment 49 André Klapper 2007-10-23 12:44:37 UTC
*** Bug 488543 has been marked as a duplicate of this bug. ***
Comment 50 Milan Crha 2007-10-24 09:58:07 UTC
(In reply to comment #47)
> Created an attachment (id=97543) [edit]
> Patch to display birthday ages correctly in calendar
> 

Seems to me like working (at least the idea, patch format is quite new for me and I'm not sure which functions were on mind to the commenter there) :) But please reopen bug #300584 for this and place patch there with a changelog entry too, (it's the reason why I obsoleted it here). Thanks in advance.
Comment 51 André Klapper 2007-10-28 22:49:25 UTC
*** Bug 491153 has been marked as a duplicate of this bug. ***
Comment 52 André Klapper 2007-11-05 16:05:20 UTC
*** Bug 493733 has been marked as a duplicate of this bug. ***
Comment 53 Simon Hepburn 2007-11-10 22:56:28 UTC
Following up from: https://bugs.launchpad.net/evolution/+bug/48679

This bug is still present in Ubuntu 7.10/Evo 2.12.

I can also confirm the additional problem noted in the Ubuntu bug report by Barry Michels in Comment #15:

https://bugs.launchpad.net/evolution/+bug/48679/comments/15

It seems to be more than a simple locale issue - there is something seriously flawed with Evo's date calculations. For those of us with a locale setting that won't permit entering four-digit years in Evo, you can verify this by installing Openhand's Contacts which also uses EDS for storage:

#apt-get install contacts

Contacts uses four-digit years to edit birthdates stored in EDS. If you edit a contact record with Contacts to correct a birthdate of say 2066 to 1966 and then go to that date in 2007 in Evo's Birthdays & Anniversarys Calendar you would expect to see an entry with (41) after it to indicate that date is that contact's 41st birthday. According to Evo however that person is 38 years old in 2007. Interesting maths!

I verified that Contacts stores the date correctly in EDS by installing GBirthday which also uses EDS. The dates of upcoming birthdays (and ages) that have been corrected with Contacts are displayed correctly by GBirthday.
Comment 54 André Klapper 2007-11-11 11:50:21 UTC
*** Bug 495486 has been marked as a duplicate of this bug. ***
Comment 55 Simon Hepburn 2007-11-11 16:44:00 UTC
Created attachment 98921 [details]
screenshot of Evo Calendar incorrectly calculating ages

After a bit of playing around with some test contacts it's obvious what Evolution's  Birthdays & Anniversarys Calendar is doing with birthdates - anyone born before 1970 has the same age regardless of year they were born and is assumed to have been born in 1970.  Attached screenshot shows 3 test contacts born 11th Nov in 1937, 1947 and 1957. Birthdates stored in EDS by Evo were corrected from 2037, 2047 and 2057 using Open Hand's Contacts. Evolution Calendar erroneously shows all three having the same age. GBirthday shows their correct age as calculated from birthdates stored in EDS. 

Is this a symptom of the same bug or should it be reported separately?
Comment 56 Milan Crha 2007-11-12 10:14:07 UTC
The issue you mention is because of bug, which solves patch from comment #47, but it has unfortunately not much to do with this bug, but should be added to bug #300584 which is about showing ages in calendar. Also, as Peter said in comment #46, there is a "FIXME" comment in a contact backend, which need to be fixed to let it work. his patch do that, but I'm not sure if that fix will not break anything. What do you think, Chen?
Comment 57 Chenthill P 2007-11-15 17:39:36 UTC
The patches seems to work fine as explained at comment #41. As Nathan pointed out, its better to make the UI less confusing by allowing the users to enter only 4 digit values for years. Srini, what would be your opinion on this ?

One behavior change which I noticed with the patch is selecting the entry of the birthday field and moving to another field sets the current date to the field. The only way to reset is to open the calendar and select none.
Comment 58 Milan Crha 2007-11-16 12:16:31 UTC
Fix from comment #47 has been committed in bug #300584. (Look there for details.)
Comment 59 Srinivasa Ragavan 2007-11-18 08:27:32 UTC
Chen, Im fine to make it to 4 digits.
Comment 60 André Klapper 2007-11-26 15:59:47 UTC
*** Bug 499188 has been marked as a duplicate of this bug. ***
Comment 61 André Klapper 2007-11-26 16:04:19 UTC
*** Bug 499293 has been marked as a duplicate of this bug. ***
Comment 62 André Klapper 2007-12-30 14:52:58 UTC
*** Bug 506411 has been marked as a duplicate of this bug. ***
Comment 63 André Klapper 2008-01-02 09:47:58 UTC
*** Bug 506637 has been marked as a duplicate of this bug. ***
Comment 64 André Klapper 2008-01-02 09:57:55 UTC
*** Bug 506627 has been marked as a duplicate of this bug. ***
Comment 65 André Klapper 2008-01-02 19:03:47 UTC
*** Bug 506832 has been marked as a duplicate of this bug. ***
Comment 66 Milan Crha 2008-01-04 14:16:30 UTC
srag, chen, so approved/rejected/needs-work?
Comment 67 André Klapper 2008-01-05 12:30:40 UTC
*** Bug 507466 has been marked as a duplicate of this bug. ***
Comment 68 Srinivasa Ragavan 2008-01-05 16:24:07 UTC
Milan, I would leave it to Chen to decide :)
Comment 69 André Klapper 2008-01-06 10:37:03 UTC
This is getting a dup per day, setting blocker status.
Comment 70 André Klapper 2008-01-06 10:37:18 UTC
*** Bug 507602 has been marked as a duplicate of this bug. ***
Comment 71 Srinivasa Ragavan 2008-01-07 09:30:31 UTC
Milan, Can you commit it to trunk? Chen is fine and I'm fine. Which means commit :)
Comment 72 Milan Crha 2008-01-07 11:46:55 UTC
eds part committed to trunk. Committed revision 8343.
evo part committed to trunk. Committed revision 34774.
Comment 73 André Klapper 2008-01-07 12:15:03 UTC
is it possible to also get this into stable, or does it break any freezes?
Comment 74 Milan Crha 2008-01-07 12:25:37 UTC
there are new API(?) functions exported from eds libraries, used in evo. I guess this can be a trouble (or not, I do not know).
Comment 75 Srinivasa Ragavan 2008-01-07 13:38:06 UTC
Andre, this adds new apis to EDS
Comment 76 André Klapper 2008-01-07 16:51:40 UTC
ah, understand. thanks! and another 2.22 blocker fixed...


THIS BUG HAS BEEN ALREADY FIXED IN THE UNSTABLE DEVELOPMENT VERSION AND WILL BE FIXED IN THE UPCOMING EVOLUTION 2.22 RELEASE (MARCH 2008).
Comment 77 André Klapper 2008-01-18 18:49:01 UTC
*** Bug 510416 has been marked as a duplicate of this bug. ***
Comment 78 André Klapper 2008-01-22 10:48:07 UTC
*** Bug 511198 has been marked as a duplicate of this bug. ***
Comment 79 André Klapper 2008-02-11 17:25:01 UTC
*** Bug 515782 has been marked as a duplicate of this bug. ***
Comment 80 André Klapper 2008-02-11 22:24:06 UTC
*** Bug 515869 has been marked as a duplicate of this bug. ***
Comment 81 André Klapper 2008-02-16 22:23:18 UTC
*** Bug 516909 has been marked as a duplicate of this bug. ***
Comment 82 André Klapper 2008-02-17 19:55:27 UTC
*** Bug 517042 has been marked as a duplicate of this bug. ***
Comment 83 André Klapper 2008-02-25 08:29:34 UTC
*** Bug 518499 has been marked as a duplicate of this bug. ***
Comment 84 André Klapper 2008-02-25 08:29:49 UTC
*** Bug 518490 has been marked as a duplicate of this bug. ***
Comment 85 André Klapper 2008-02-25 08:36:59 UTC
*** Bug 518129 has been marked as a duplicate of this bug. ***
Comment 86 André Klapper 2008-03-02 20:38:47 UTC
*** Bug 519967 has been marked as a duplicate of this bug. ***
Comment 87 Milan Crha 2008-03-14 17:14:30 UTC
*** Bug 306945 has been marked as a duplicate of this bug. ***
Comment 88 André Klapper 2008-03-20 15:14:15 UTC
*** Bug 523431 has been marked as a duplicate of this bug. ***
Comment 89 André Klapper 2008-03-22 19:01:31 UTC
*** Bug 523829 has been marked as a duplicate of this bug. ***
Comment 90 André Klapper 2008-03-31 15:29:26 UTC
*** Bug 524448 has been marked as a duplicate of this bug. ***
Comment 91 André Klapper 2008-04-02 18:58:45 UTC
*** Bug 524677 has been marked as a duplicate of this bug. ***
Comment 92 André Klapper 2008-04-12 12:21:34 UTC
*** Bug 527693 has been marked as a duplicate of this bug. ***
Comment 93 André Klapper 2008-04-25 16:12:27 UTC
*** Bug 529894 has been marked as a duplicate of this bug. ***
Comment 94 André Klapper 2008-04-27 16:18:02 UTC
*** Bug 530168 has been marked as a duplicate of this bug. ***