lennox@cs.columbia.edu wrote:
My only concern would be whether anything doing GNOME-style behavior then wants to pass the minimum timestamp to localtime() or the like, which will fail for timestamps repesenting years earlier than -2^31 - 1900.
Thanks, that is a possible bug that I hadn't considered. Unfortunately that boundary's value is INT_MIN - 1900, and INT_MIN isn't necessarily -2**31. For example, on Unisys ClearPath enterprise servers INT_MIN is 1 - 2**39; because tz binary files are supposed to be usable even on these unusual platforms, hardwiring -2**31 - 1900 into them would cause an unwanted glitch at the 32-bit boundary on these platforms. Conversely, if we used the conservative boundary -32767 - 1900 (which the C standard says should be representable on all platforms), we would insert an unwanted glitch on nearly every platform. And even on the oddball platform where INT_MIN == -32767 there could be problems within a few hours of the boundary, due to software being confused about localtime succeeding but gmtime failing or vice versa. I think this possible bug is less likely than the GNOME bug, so I'm inclined try the Big Bang and see whether it breaks anything compared to 2014b. If not, we can declare victory; otherwise, we can look into adjusting the boundary according to whatever other library bug we run into. In private email, Arthur David Olson pointed out that zic would still let pre-Big-Bang leap seconds slip through; the attached further patch (which I've pushed to the experimental repository) fixes this.