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



Hi Jeff:

Am 26.03.17 14:50 schrieb(en) Jeffrey Stedfast via balsa-list:
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 wonder if this interface actually works for all cases, as the docs for 2.6 say "int *tz_offset: pointer to 
timezone offset (in +/- hours)".  But some time zones do not have an integral offset relative to utc (e.g. India = 
5 hours 30 minutes - for ~1.2 * 10**9 people!).

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?

It would require changing the message object in Balsa to use a GDateTime * instead of a time_t.  I think the 
changes are rather limited and not difficult.  The work of a rainy November afternoon... ;-)

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).

GLib comes with g_date_time_format().  Or use g_date_time_to_unix() which has the advantage to be 
year-2038-safe on 32-bit boxes (if any of them still work in 2038).

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.

I strongly vote for using GLib types wherever possible.  I.e. not only GDateTime, but also gint instead of 
int, gssize vs. ssize_t, etc. etc.  Even using types from e.g. stdint will not always be sufficient, as there 
are some broken compilers around which do not fully implement C standards.  Like M$VC, which doesn't even 
comply fully with IEC9899:1999.  So let the GLib guys deal with that crap...

Just my €0.01, though...  Peter?  Pawel?

Cheers,
Albrecht.

Attachment: pgpC2kks1SXkF.pgp
Description: PGP signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]