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

[Jeffrey Stedfast <jestedfa microsoft com>]

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:balsa-list-bounces gnome org] On Behalf Of Jeffrey
> Stedfast via balsa-list
> Sent: Sunday, March 26, 2017 2:07 PM
> To: Albrecht Dreß <albrecht dress arcor de>
> Cc: balsa-list gnome org
> Subject: RE: RFC: should GMime use GDateTime instead of time_t?
>
> Hey Albrecht,
>
> > -----Original Message-----
> > From: Albrecht Dreß [mailto:albrecht dress arcor de]
> > Sent: Sunday, March 26, 2017 10:54 AM
> > To: Jeffrey Stedfast <jestedfa microsoft com>
> > Cc: balsa-list gnome org
> > 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
> balsa-list gnome org
> https://mail.gnome.org/mailman/listinfo/balsa-list