<div dir="ltr">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.<div>
<br></div><div>-Andrew</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 23, 2014 at 4:45 PM, Paul Eggert <span dir="ltr"><<a href="mailto:eggert@cs.ucla.edu" target="_blank">eggert@cs.ucla.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 05/23/2014 02:27 PM, Leonardo Chiquitto wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
After updating to 2014c, we've received a couple of reports<br>
of applications that started to misbehave (show wrong times).<br>
One example is the clock applet from Gnome3<br>
</blockquote>
<br></div>
Thank you for the heads-up.<br>
<br>
Do all the broken applications use Glib (the Gnome library)? If so, thisappears to be Gnome bug 730332, which you can view here:<br>
<br>
<a href="https://bugzilla.gnome.org/show_bug.cgi?id=730332" target="_blank">https://bugzilla.gnome.org/<u></u>show_bug.cgi?id=730332</a><br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
I'll CC: this to Arthur David Olson to see whether he has a better idea.<br>
</blockquote></div><br></div>