RFC: should GMime use GDateTime instead of time_t?

[David Bremner]

Jeffrey Stedfast <jestedfa at microsoft.com> writes:

> Hey all,
>
> Currently, g_mime_message_get_date() is somewhat awkward in that it returns a time_t but also has a int *tzone parameter that gets set to the timezone offset.
>
> I only just recently even discovered that Glib had a GDateTime and thought *maybe* it might be a better alternative, but figured I'd check with the 2 main projects using GMime to see what your thoughts were.
>
> Would it make your tasks easier? Harder?

I think there would be a bit of short term pain, as we currently
serialize the time_t into a xapian database. To avoid re-indexing we'd
probably end up converting the GDateTime into a
time_t. g_date_time_get_seconds returns a double, so in the case that
time_t is 64 bits we would theoretically be losing precision (maybe only
after year 2038?), but xapian serialization takes a double anyway, so I
guess there's no real loss.

The other small practical issues are another place dealing with glib
allocated memory, and ifdefing around the two APIs.

So I think we could cope, and wouldn't want to stand in the way if there
were concrete benefits, but afaik easiest for us is the status
quo. Maybe Jani in CC has further comments, since he wrote the date-time
parsing library we are using.

d