On 9/13/21 6:38 AM, Michael H Deckers wrote:
Isn't it quite simple to compute the fictitious local time LT: when UTC is 1972-06-30T23:59:59Z then LT is 1972-07-01T01:23:44 1972-06-30T23:59:60Z then LT is not well-defined
If we took that approach, shouldn't calls to 'localtime' fail during a positive leap second? After all, localtime is not well-defined. Clearly we can't do that; too much code expects localtime to succeed unless the time_t value is extremely large or small. localtime must generate *something*, even though it's bogus according to the abovementioned approach. Unfortunately, whatever value localtime plausibly generates will lead to ambiguity in timestamps. And ambiguity is a real problem for users. If I understand things correctly, you're saying that if the UTC offset is a multiple of 60 seconds, then localtime is well-defined during a positive leap second because it ends in :60. Otherwise, localtime is not well-defined during a positive leap second. The proposed patch generalizes in a better way. It says that localtime is well-defined at all times: the minute containing the leap second has seconds numbered 0 through 60, with the leap second being one of those seconds. There is no ambiguity about which second a localtime label identifies, and no second in which localtime is undefined. And the UTC offset remains constant.
In your proposal, LT - TAI and UTC - TAI have discontinuities at different values of TAI so that LT - UTC just cannot be constant.
Such a problem doesn't occur if one uses a proper mapping from broken-down time to seconds counts. In the proposed patch, the mapping from broken-down time (date, hours, minutes, seconds) to LT (a seconds count) takes a within-minute positive leap second into account. LT - UTC is constant because LT - TAI and UTC - TAI have discontinuities at the same instant. Please see my recent email to John Sauter for another way to look at this. In thinking about this more, we have a tradeoff here. When dealing with positive leap seconds, is it more important to have unambiguous timestamps, or to have a simple way to calculate UTC offsets without using tm_gmtoff? If the former, the proposed patch is better; if the latter, then 2021a is better. For end users I think it's quite clear that unambiguous timestamps are better. If there's a real need to calculate UTC offsets without using tm_gmtoff, I think one can write a function to do that that will work even with the proposed patch present. Such a function isn't needed for current tzdb, though, since the situation in question cannot occur in the existing database. So writing such a function should be low priority.