I gave moving to GDateTime a go last night and have an implementation that *almost* works, but I can't get it to work quite right.
When the timezone is "EDT" or "-0400", g_time_zone_new(const char *name) returns a GTimeZone just fine and I pass it off to g_date_time_new(), but if I then ask for the UTC offset from the GDateTime, I get back 0. If I change the string to "EST" or "-0500", everything works perfectly and I get back exactly the UTC offset that I would expect (-5 hours). The same for using "GMT" or "+0000". I *suspect* that the problem might be that GTimeZone is locale-sensitive or something and perhaps g_date_time_new() assumes I'm trying to construct a locale or UTC date? Frankly, it also kinda sucks that GTimeZone doesn't have a way to create a timezone based on a known UTC offset rather than a string that God-knows if it'll parse it in the way I expect/hope it will. From what I could tell by skimming over the source code (comments mostly), g_time_zone_new() *should* correctly parse the timezone names *and* the numeric offsets used in message Date headers correctly, but if it is... why is it giving me a big fat 0 for "-0400" and "EDT"? I might have to figure out who to poke in the GNOME community about this to get some answers on how this is supposed to work and/or if my suspicions are correct. Jeff > -----Original Message----- > From: balsa-list [mailto:[email protected]] On Behalf Of Jeffrey > Stedfast via balsa-list > Sent: Sunday, March 26, 2017 2:07 PM > To: Albrecht Dreß <[email protected]> > Cc: [email protected] > Subject: RE: RFC: should GMime use GDateTime instead of time_t? > > Hey Albrecht, > > > -----Original Message----- > > From: Albrecht Dreß [mailto:[email protected]] > > Sent: Sunday, March 26, 2017 10:54 AM > > To: Jeffrey Stedfast <[email protected]> > > Cc: [email protected] > > Subject: 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!). > [Jeffrey Stedfast] > > The integer offset isn't in number of hours, it's in seconds I believe. I > know it > works for x:30 timezones. So that's not an issue. > > > > > > 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... ;-) > [Jeffrey Stedfast] > > I don't think switching to GDateTime would take too much effort. Certainly > doable in a single night of hacking. > > > > > > 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). > [Jeffrey Stedfast] > > True... although I suspect most machines will be 64bit by then. Most are 64bit > now, although oddly still running a lot of 32bit software on 64bit machines. > > > > > > 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... > [Jeffrey Stedfast] > > I mostly wanted to make sure it wouldn't be a hastle and it sounds like it > wouldn't be... > > Jeff > > _______________________________________________ > balsa-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/balsa-list _______________________________________________ balsa-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/balsa-list
