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. -Andrew On Fri, May 23, 2014 at 4:45 PM, Paul Eggert <eggert@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:
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.