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

[Paul Eggert]

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, 
thisappears to be Gnome bug 730332, which you can view here:

https://bugzilla.gnome.org/show_bug.cgi?id=730332

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.

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.

A simple workaround is to back out the two zic.c changes you mentioned.  
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.