Quantcast

RFC: should GMime use GDateTime instead of time_t?

classic Classic list List threaded Threaded
2 messages Options
Jeffrey Stedfast-2 Jeffrey Stedfast-2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RFC: should GMime use GDateTime instead of time_t?

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 personally don't mind the time_t API, especially since it's unlike you'll be adding/subtracting time from it and there are already ways of formatting date strings with it (for display purposes).

I haven't really played with GDateTime so I don't know how useful it would really be. Hoping that maybe some of you guys *have* and will perhaps have an opinion one way or the other (e.g. "for the love of God, yes! Please use GDateTime!" or "Oh hellllllll no!". If not, I'll probably just leave it as it is.

Thoughts?

Jeff

_______________________________________________
notmuch mailing list
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch
David Bremner-2 David Bremner-2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFC: should GMime use GDateTime instead of time_t?

Jeffrey Stedfast <[hidden email]> 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



_______________________________________________
notmuch mailing list
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch
Loading...