still in 2.5.4, retargetting

something like that:
/* To translators: %s is the name of the person, and %d is the age (in years) */"

i feel free to assign this bug, feel free to reassign. neni zac. ;-)

Created attachment 89609 [details] [review]
proposed patch

for evolution;

It adds " (#)" after a summary text of the event if this event is in Birthday or Anniversary category, but only if start year minus actual year is bigger than 0. (Doesn't add value into the first occurrence.) It adds this "year info" into tooltip too. It only didn't work in list-view mode.

Andre: jo jo, diky moc :)

Looks fine Milan. But doesn't it introduce warnings due to assigning to a const variable?

I tried this on actual trunk with and without a patch and no new warning there. So it may be fine. (changing 'needs-work' flag to 'none')

ah! you are right. I was reviewing it and confused by the const assignment. Sorry for the spam. But Is it working for you? Im not able to get this working. The patch seems fine. But Im missing some thing to work.

Yes, it is :)
Add a person to local contact list, and setup there a Birthday to 12062007 and Anniversary 13062007, then go to Calendar, check "Birthdays & Anniversaries" and look on 12062007 or 13062007 will *not* add there any (#) as sufix, because that's a beginning ( "(0)" look strange), but in view of year 2008, it *will*.

+/* e_calendar_view_get_icalcomponent_summary returns summary of calcomp,
+ * and for type of birthday or anniversary it append number of years since
+ * beginning. In this case, the free_text is set to TRUE and caller need
+ * to g_free returned string, otherwise free_text is set to FALSE and
+ * returned value is owned by calcomp.
+ */
+
+const gchar *
+e_calendar_view_get_icalcomponent_summary (icalcomponent *icalcomp, gboolean *free_text)


Wouldn't it be better to just always return a newly-allocated string, rather than forcing the caller to fuss with deciding whether or not to free it?

Perhaps just build up a GString like so:

gchar *
e_calendar_view_get_icalcomponent_summary (icalcomponent *icalcomp)
{
	GString *string;

	g_return_val_if_fail (icalcomp != NULL, NULL);

	string = g_string_new (icalcomponent_get_summary (icalcomp));

	if (icalcomp_contains_category (icalcomp, _("Birthday")) ||
	    icalcomp_contains_category (icalcomp, _("Anniversary"))) {
		struct icaltimetype dtstart, dtnow;

		dtstart = icalcomponent_get_dtstamp (icalcomp);
		dtnow = icalcomponent_get_dtstart (icalcomp);

		if (dtnow.year - dtstart.year > 0)
			g_string_append_printf (
				string, " (%d)", dtnow.year - dtstart.year);
	}

	return g_string_free (string, FALSE);
}

I did it like this only because there are only two categories, for which is this relevant and for almost all events you don't need to allocate any extra memory, so it's "safer" for memory. It looks strange for me to always allocate memory when it is not necessary.

I tried this patch tonight but it doesn't seem to work. I have a bunch of contacts in the default local addressbook with either birthday or anniversary set and neither shows up.

What did I miss ?

You need to have checked that "Birthdays & Anniversaries" in a calendar tree under "Contacts" node to show this in calendar. Maybe this?

it is checked, i cannot get it to work either. :-(

patch with debug output appreciated, because i want this feature :-)

the year check does not match against the birthyear, but against the creation year of that contact in evo, it seems

Created attachment 89939 [details] [review]
proposed patch

for evolution;

second chance :) This works better.

patch works fine here, i sometimes had problems (e.g. repainting issue when changing an anniversary by one year => not displayed in main window, but in mini calendar, like bug 353012, but in day view), and one big issue is still bug 339813 and bug 244382.

*every* person born before 1970 will be displayed as 37/38 years old. we need either a fix or a workaround (check year of birth and don't display age if born before 1970?) for this issue.

(cool, birthdays on a feb 29th actually work and get displayed on 28th in other years. nice, nice.)

(correction: looks like the repainting issue would be fixed by the patch at bug 311098)

now it works for me too, thanks for the patch :)

Patch looks good. Committed to svn HEAD.

Created attachment 98969 [details]
Evolution Birthday Calendar showing wrong ages.

Still borked in Evolution 2.12.1

Attached screenshot shows 3 test contacts born 11th Nov in 1937, 1947 and 1957. Evolution Calendar erroneously shows all three having the same age. GBirthday shows their correct age as calculated from birthdates stored in EDS.

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 went through the bug 253885 for which the above patch was made. I think this part of the hack can be removed. Please commit the patch attached at http://bugzilla.gnome.org/show_bug.cgi?id=339813#c47.

Fix from the above link has been committed to trunk. Committed revision 8216.
And also to stable. Committed revision 8217.

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

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