Birthdays before 1969 shows as birthdays in the future 2000+

Thanks for your bug. What version of Ubuntu and locale do you use? How do you enter the birthday, with the calendar by picking a date or with the keyboard?

Da_DK

Both Calendar and keyboard.

what version of Ubuntu do you use?

Dapper

That bug is known upstream: http://bugzilla.gnome.org/show_bug.cgi?id=339813, I've added a comment pointing the ubuntu page for it

Still the same issue with Edgy, Evolution 2.8.1 and locale en_US :(

Also posted to the Gnome-Bugzilla, and hopefully this gets solved very soon!

Still here in Feisty.

Version Information
Ubuntu Feisty (Herd 5)
evolution 2.9.92-0ubuntu1

AAARGH!

Yeah, Alex, I see that you want to make the devs see again, that the bug is still there, and I completely understand that.

I think this bug shouldn't be in a "reference application" for Gnome (and also Ubuntu).

It's a pity that "Contacts" doesn't let one add a birthday to a contact and so one has to stick with the crappy evolution...

Guillermo Gutiérrez Herrera explained how to fix this on #118418:

   | If you change d_fmt in LC_TIME sections for all of the locales reporting issues
   | on this, from %y (last two-digits year) to %Y (four-digits year) you will fix the bug
   | #48679 in evolution. Thanks.

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

I can see why the locale affects input but I don't like the current implementation. If I enter 01/10/07 on a British locale I expect it to be interpreted as the 1st October 2007 not the 10th January 2007 (also notice how I expect the year to have been expanded to four digits). However there's a fair case for years to always be entered as four digits and two digit year entry to be simply rejected.

evolution works as wished with this patch to langpack-locales for es_ES:

diff -NaurtwB langpack-locales-2.3.23/locales/es_ES langpack-locales-2.3.23guillex1/locales/es_ES
--- langpack-locales-2.3.23/locales/es_ES 2006-12-14 06:33:29.000000000 +0100
+++ langpack-locales-2.3.23guillex1/locales/es_ES 2007-06-02 20:30:03.000000000 +0200
@@ -132,7 +132,7 @@
         "<U006E><U006F><U0076><U0069><U0065><U006D><U0062><U0072><U0065>";/
         "<U0064><U0069><U0063><U0069><U0065><U006D><U0062><U0072><U0065>"
 d_t_fmt "<U0025><U0061><U0020><U0025><U0064><U0020><U0025><U0062><U0020><U0025><U0059><U0020><U0025><U0054><U0020><U0025><U005A>"
-d_fmt "<U0025><U0064><U002F><U0025><U006D><U002F><U0025><U0079>"
+d_fmt "<U0025><U0064><U002F><U0025><U006D><U002F><U0025><U0059>"
 t_fmt "<U0025><U0054>"
 am_pm "";""
 t_fmt_ampm ""

I have the same problems with my installation, feisty all updates applied.
dates after 1969 work, 1968 dont.

I was about to post a new bug report, but I think it's related to this one.

Birthdays and Anniversaries before 1970 do not calculate properly. For example, create a new contact with a birthday in 1949 and when you go to the calendar, it says he'd be 38 years old in 2008. I'm entering the date as 01/01/1949 so there won't be any ambiguity.

Still present in Gutsy/ Evo 2.12.

I can also confirm the additional problem noted above by Barry Michels, 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.

Will copy this to upstream bug.

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?

Will copy upstream.

Upstream have reported that the birthday calendar age issue is known about and is being treated as a separate bug:

http://bugzilla.gnome.org/show_bug.cgi?id=300584

It's marked as fixed in 2.11.x but the bug still exists in 2.12.1

Perhaps Ubuntu bug #145657 should be re-opened and an upstream bug watch added?

In my endeavors to find the source of this bug, I came across this snippet from evolution-data-server/calendar/backends/contacts/e-cal-backend-contacts.c:

static struct icaltimetype
cdate_to_icaltime (EContactDate *cdate)
{
        struct icaltimetype ret;

/*FIXME: this is a really _ugly_ (temporary) hack
 * since several functions are still depending on the epoch,
 * let entries start (earliest) at 19700101
 */
        ret.year = cdate->year >= 1970 ? cdate->year : 1970;
        ret.month = cdate->month;
        ret.day = cdate->day;
        ret.is_date = TRUE;
        ret.is_utc = FALSE;
        ret.zone = NULL;
        ret.is_daylight = FALSE;

        ret.hour = ret.minute = ret.second = 0;

        return ret;
}

The above "temporary hack" has been in there since revision 3557 in March 2004...
http://svn.gnome.org/viewvc/evolution-data-server/trunk/calendar/backends/contacts/e-cal-backend-contacts.c?view=log

I've got the same bug en Gutsy and in Hardy. Alsow pjvolders of the dutch ubuntu forum has the same issue. See http://forum.ubuntu-nl.org/topic/20625. I hope there is somebody working on it?

Indeed I am experiencing the bug. Very irritating, but the source seems to be found so hopefully it gets fixed soon!

cheers,
PJ

This has been fixed upstream, thanks.

Thanks a lot :-)

This bug was fixed in the package evolution - 2.21.5-0ubuntu1

---------------
evolution (2.21.5-0ubuntu1) hardy; urgency=low

  * New upstream version:
    New in 2.21.5:
    Mail errors are now non-intrusive
    RTL fixes - Mail and Addressbook
    Bug fixes:
    - #211353: Allow categories to be assigned to emails
    - #219197: Quit application when session dies
    - #270605: Skip disabled accounts.
    - #300336: Added checkbox for "Enable Search Folders" option
    - #300336: Ensure vfolder is running.
    - #309432: Fix message headers for RTL languages.
    - #317823: Bump GtkHTML requirement to 3.17.5
    - #317823: Save inline pictures embedded into HTML Mails
    - #327965: Fixed multiple password prompts in an exchange account
    - #329692: Get the content size of the MIME part
    - #333695: Print attenddes/roles in the print view
    - #339813: Setting new option
               'e_date_edit_set_twodigit_year_can_future' to FALSE (LP: #48679)
    - #348638: Remove pre-edit buffer cleanly in day view
    - #350932: Enable the use of scrollable tabs in the mail-preferences dialog.
    - #362638: Overhaul the message passing API
    - #364642: New option in Composer tab to preset Request
               Read Receipt in composer (LP: #67683)
    - #375580: Use ISO-8859-1 encoding to store contacts in iPod
    - #448441: Disable "OK" and "Edit Full" buttons if no source is selected.
               Also set always book from combo, do not use the new created
    - #457842: Do not call edit/start editing of the event when double clicked
               on the same component as is actually editing
    - #474118: Check for the right type of store
               and invoke appropriate functions (LP: #145458)
    - #476264: Add mnemonic_widget for default junk plugin
    - #488213: Fix locks when displaying e-mail with large tiff drawing attached
    - #492188: Use the new Tangoized icons
               instead of deprecated icons from gnome-icon-theme.
    - #492702: Just disable the dbus message part of mail notification if dbus
               isn't there. Also remove new-mail-notify plugin
    - #496301: Clean up the schema
    - #496402: Do not synchronize blocked bodies from pidgin
    - #497914: backport changes from the copy/pasted code in imap-headers plugin
    - #498095: Fix mnemonic issues
    - #499145: Follow RFC 3798 to send return receipts.
    - #502303: Plugins configure widgets are not freed correctly
               in plugin-mamager
    - #502783: Restore message states
    - #502914: Do not write NULL into gconf
    - #503954: Accept custom domain names while setting up account (LP: #179512)
    - #504480: Increases the height of the ETaskBar to eliminate
               the constant resizing
    - #504541: Add --with[out]-help option to make it possible to skip building
               and installing user documentation
    - #506772: Not-NULL check for a string array before finding its length
    - #506814: Add the signal only if the view is present (LP: #173485)
    - #507067: Can't save pictures embedded in HTML Mail when picture = link
    - #507311: Submit bugs to the "BugBuddyBugs" Bugzilla component
    - #507363: Al...

Now that the but is fixed. How do I update my version of evolution? I currently show that I have version 2.12.1 and the information above says that the bug is fixed in 2.21.5. I have tried to use the Update manager to see if the new version is available, and it has not said that it is? What Now?

Thanks!

Version 2.21.5 is available in Hardy (the development version of
Ubuntu, which will be released in April). To get it into Gutsy this
would need a Stable Release Update, but I don't think it qualifies for
it (as it is no security vulnerability, crash nor important regression
from previous releases).

If you are really interested in using this new version I guess your
best option would be to request a backport. See
https://help.ubuntu.com/community/UbuntuBackports for information
about this.