Created attachment 64327 [details]
Screenshot

Proof.

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

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.

I can also confirm this bug for en_US.

I can confirm this bug for cy_GB.

could be related or even a duplicate of bug 306945

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.

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.

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

I'm using Evolution 2.6.1...

I'm alsousing Evolution 2.6.1 and I can reproduce it using en_US

poornima, as long as you do not provide information which locale you use, a "WORKSFORME" is pretty useless.

I can also reproduce it using 2.6.1 and locale nl_NL

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.

*** Bug 346747 has been marked as a duplicate of this bug. ***

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

*** Bug 351556 has been marked as a duplicate of this bug. ***

*** Bug 352184 has been marked as a duplicate of this bug. ***

*** Bug 352787 has been marked as a duplicate of this bug. ***

Confirmed with ca_ES as well; evo 2.6.3.

I can confirm this bug with es_ES and Evolution 2.8.1 (ubuntu edgy)

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

*** Bug 386668 has been marked as a duplicate of this bug. ***

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.

Nathan:
If you are using US localization then this bug won't affect you.

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.

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!

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. 

*** Bug 406367 has been marked as a duplicate of this bug. ***

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 :)

(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

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

*** Bug 417938 has been marked as a duplicate of this bug. ***

/As if/ we have a Y2K bug in Evolution.

Still present in 2.10.1 en_US (I know, "me too" syndrome). Particularly annoying, because apparently four-digit years aren't "valid dates".

The locale setting depicts an *output formatting* for dates. I don't see how this should have ever been applied to *input parsing*.

another option would be to force the use of four digit year numbers by displaying "00.00.0000" instead of the "None" string.

(In reply to comment #3)
> Is evolution just using something like strftime(3)'s "%x" argument to format
> the date?

no - see bug 336253.

@mcrha: seen bug 306945 comment 4 ?

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.

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

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.

CCing chen, as some of the calendar code gets impacted.

*** Bug 486375 has been marked as a duplicate of this bug. ***

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 :-(

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

Created attachment 97543 [details] [review]
Patch to display birthday ages correctly in calendar

*** Bug 489352 has been marked as a duplicate of this bug. ***

*** Bug 488543 has been marked as a duplicate of this bug. ***

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

*** Bug 491153 has been marked as a duplicate of this bug. ***

*** Bug 493733 has been marked as a duplicate of this bug. ***

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.

*** Bug 495486 has been marked as a duplicate of this bug. ***

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?

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?

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.

Fix from comment #47 has been committed in bug #300584. (Look there for details.)

Chen, Im fine to make it to 4 digits.

*** Bug 499188 has been marked as a duplicate of this bug. ***

*** Bug 499293 has been marked as a duplicate of this bug. ***

*** Bug 506411 has been marked as a duplicate of this bug. ***

*** Bug 506637 has been marked as a duplicate of this bug. ***

*** Bug 506627 has been marked as a duplicate of this bug. ***

*** Bug 506832 has been marked as a duplicate of this bug. ***

srag, chen, so approved/rejected/needs-work?

*** Bug 507466 has been marked as a duplicate of this bug. ***

Milan, I would leave it to Chen to decide :)

This is getting a dup per day, setting blocker status.

*** Bug 507602 has been marked as a duplicate of this bug. ***

Milan, Can you commit it to trunk? Chen is fine and I'm fine. Which means commit :)

eds part committed to trunk. Committed revision 8343.
evo part committed to trunk. Committed revision 34774.

is it possible to also get this into stable, or does it break any freezes?

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

Andre, this adds new apis to EDS

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

*** Bug 510416 has been marked as a duplicate of this bug. ***

*** Bug 511198 has been marked as a duplicate of this bug. ***

*** Bug 515782 has been marked as a duplicate of this bug. ***

*** Bug 515869 has been marked as a duplicate of this bug. ***

*** Bug 516909 has been marked as a duplicate of this bug. ***

*** Bug 517042 has been marked as a duplicate of this bug. ***

*** Bug 518499 has been marked as a duplicate of this bug. ***

*** Bug 518490 has been marked as a duplicate of this bug. ***

*** Bug 518129 has been marked as a duplicate of this bug. ***

*** Bug 519967 has been marked as a duplicate of this bug. ***

*** Bug 306945 has been marked as a duplicate of this bug. ***

*** Bug 523431 has been marked as a duplicate of this bug. ***

*** Bug 523829 has been marked as a duplicate of this bug. ***

*** Bug 524448 has been marked as a duplicate of this bug. ***

*** Bug 524677 has been marked as a duplicate of this bug. ***

*** Bug 527693 has been marked as a duplicate of this bug. ***

*** Bug 529894 has been marked as a duplicate of this bug. ***

*** Bug 530168 has been marked as a duplicate of this bug. ***