On 05/23/2014 02:27 PM, Leonardo Chiquitto wrote:Thank you for the heads-up.
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
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.