[tz] tzcode-2014c breaks applications that use the binary tz files

[Brian Inglis]

On 2014-05-25 13:25, Paul Eggert wrote:
> lennox at 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.

Given that all tz dates are in the Gregorian calendar, the
first date observed in that calendar
Fri, 15 Oct, 1582 00:00:00 which is Unix time -12219292800
on 64 bit time_t systems should be sufficiently early and
within the ctime limitation of 4 digit years?

It will also never be adjusted, unlike the current Big Bang estimate.

All dates prior to that date have to be interpreted as Julian dates,
and 10 days subtracted because of the Gregorian date adjustment.

Alternatively Thu, 14 Sep, 1752 00:00:00 Unix time -6857222400
could be used, as the last date on which a large number of countries
adopted the Gregorian calendar, and is still well before any adoption
of Standard times and zones.

All dates prior to that date may be interpreted as Julian dates,
and 11 days subtracted because of the later Gregorian date adjustment.
That date is also consistent with the output of the Unix cal command,
which drops Sep 3-13, whereas 1582 shows Oct with 31 days.
-- 
Take care. Thanks, Brian Inglis