[tz] tzcode-2014c breaks applications that use the binary tz files
andrew at ishiboo.com
Fri May 23 20:54:57 UTC 2014
Just to use as a data point, our (private) implementation that reads the
binary files also had this issue. I had to revert to 2014b to generating
the binary data until I could follow up and make sure the code was working
correctly with the newly introduced transition.
On Fri, May 23, 2014 at 4: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,
> thisappears to be Gnome bug 730332, which you can view here:
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tz