Comment 5 for bug 1216263

> #3 0x0804c0ce in indicator_datetime_planner_get_appointments (self=0x9dfbc10,
> begin=begin@entry=0x0, end=end@entry=0xb5005e78) at planner.c:188
> appointments = <optimized out>
> __PRETTY_FUNCTION__ = "indicator_datetime_planner_get_appointments"
> #4 0x0804d5d2 in get_all_appointments_this_month (self=0x9df98c8) at service.c:592
> calendar_date = 0xb5005ca8
> begin = <optimized out>
> end = 0xb5005e78
> y = 2013
> m = 8
> d = 21
> appointments = 0x0
> p = 0x9df9850

Here's the code in indicator-datetime:

> calendar_date = get_calendar_date (self);
> g_date_time_get_ymd (calendar_date, &y, &m, &d);
> begin = g_date_time_new_local (y, m, 1,
> 0, 0, 0);
> end = g_date_time_new_local (y, m, g_date_get_days_in_month(m,y),
> 23, 59, 0);
>
> appointments = indicator_datetime_planner_get_appointments (p->planner,
> begin,
> end);

So calendar_date is non-NULL and get_all_appointments_this_month() got a ymd of 2013/8/21 out of it, then created 'begin' with g_date_time_new_local (2013, 8, 1, 0, 0, 0), and passes it to indicator_datetime_planner_get_appointments(), which sees it as NULL.

So it looks like g_date_time_new_local() is returning NULL. It's a wrapper func that gets the local timezone and calls g_date_time_new(), which returns NULL if it's fed invalid arguments. 2013, 8, 1, 0, 0, 0 seem valid.

The sanity check in g_date_time_new() looks like this:

> if (year < 1 || year > 9999 ||
> month < 1 || month > 12 ||
> day < 1 || day > 31 ||
> hour < 0 || hour > 23 ||
> minute < 0 || minute > 59 ||
> seconds < 0.0 || seconds >= 60.0)
> return NULL;

seconds is a gdouble, so maybe this is a floating point accuracy issue with testing "0.0 < 0.0"?