[tz] tzcode-2014c breaks applications that use the binary tz files

Leonardo Chiquitto leonardo.lists at gmail.com
Fri May 23 20:59:25 UTC 2014


On Fri, May 23, 2014 at 10:45 PM, Paul Eggert <eggert at cs.ucla.edu> wrote:
> On 05/23/2014 02:27 PM, Leonardo Chiquitto wrote:
>>
>> After updating to 2014c, we've received a couple of reports
>> of applications that started to misbehave (show wrong times).
>> One example is the clock applet from Gnome3
>
> Thank you for the heads-up.
>
> Do all the broken applications use Glib (the Gnome library)?  If so,
> this appears to be Gnome bug 730332, which you can view here:
>
> https://bugzilla.gnome.org/show_bug.cgi?id=730332

Indeed this seems to be the problem. One of the reports was about
gdm and other Gnome applications, but we received at least one
more from a different application that also made assumptions on
the format of the binary files.

> Starting with 2014c, zic generates a transition at the minimum time value
> -2**63, to avoid ambiguities about what to do before then.  The interval_end
> function of Glib's gtimezone.c subtracts one from this, to find the end time
> of the zeroth interval (i.e., the interval containing all the "early" time
> stamps); in interval_end this subtraction overflows and wraps around to
> 2**63 - 1, which causes Glib to go off the rails and assume that *all* time
> stamps are "early".  For example, Glib computes Sao Paulo time stamps as if
> Brazil's circa-1913 rules were still in effect, i.e., as if Sao Paulo were
> at UTC-3:06:28, which is incorrect by 6 minutes 28 seconds, which is the
> error you're observing.

Thanks for the detailed background information!

> This is a serious incompatibility.  Distributions that use Glib should not
> use tz 2014c's code to generate binary files.  The 2014c data files are
> fine; it's the 2014c zic.c that's causing the incompatibility.
>
> This is clearly a bug in Glib, and I assume it'll be fixed soon, but that's
> small consolation to the people affected by it.  And one can't help but
> wonder which other software packages have similar bugs.

Yes, that's the problem. Specially when we consider that there are
probably proprietary software out there doing the same.

> A simple workaround is to back out the two zic.c changes you mentioned.

For now, this is what we're going to do as quickly as possible.

> Another possibility would be for zic.c to generate a transition at time
> -2**63 + 1 instead, so that the Glib code won't wrap around, but that sounds
> fragile.
>
> Yet another possibility might be to change zic.c to set the initial
> transition to be -2**60 instead of -2**63; this would comfortably predate
> the Big Bang so it's unlikely we'll see any real time stamps before then.
>
> I'll CC: this to Arthur David Olson to see whether he has a better idea.

Thanks for your fast response and have a nice weekend,

Leonardo


More information about the tz mailing list