On Fri, May 23, 2014 at 10: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, this appears to be Gnome bug 730332, which you can view here:
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