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:
/*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;
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
ret.is_ daylight = FALSE;
* 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.hour = ret.minute = ret.second = 0;
return ret;
}
The above "temporary hack" has been in there since revision 3557 in March 2004... svn.gnome. org/viewvc/ evolution- data-server/ trunk/calendar/ backends/ contacts/ e-cal-backend- contacts. c?view= log
http://