On 9/12/21 2:18 PM, Michael H Deckers wrote:
the comment should make it clear that the proposal only affects the behavior for the "right" system time,
Thanks, good point. Fixed in the attached patch.
On 2021-09-12 00:36, Paul Eggert via tz proposed:
+ Here is how the fix affects timestamps in a + timezone with UTC offset +01:23:45 and with a positive leap second + 78796801 (1972-06-30 23:59:60 UTC):
Oops! My text messed up. The leap second is at 78796800, not at 78796801. Sorry about the confusion; I don't know whether this affected your analysis.
+ + time_t without the fix with the fix + 78796800 1972-07-01 01:23:45 1972-07-01 01:23:45 + 78796801 1972-07-01 01:23:45 1972-07-01 01:23:46 + ... + 78796815 1972-07-01 01:23:59 1972-07-01 01:23:60 + 78796816 1972-07-01 01:24:00 1972-07-01 01:24:00 +
... such time scales will undoubtedly be specified as UTC plus or minus an offset ...
With the current version of localtime(), this condition is satisfied with the proviso that the offset between 23:59:60 and 01:23:45 is (deliberately) not (clearly) defined.
It sounds like you're saying that the situation is tricky in this area, which it certainly is (as witness my confusion!).
With the proposal, however, the condition is not satisfied; for instance, in the example given in the proposed comment, the local time would differ from UTC by T01:23:46 from 1972-07-01T00:00:00Z to 1972-07-01T00:00:14Z
I think that calculation is not quite right. With the fix, the localtime-minus-UTC value remains 5025 seconds throughout, using a calculation that takes the positive leap second into account. This can be confirmed by looking at tm_gmtoff in the affected seconds. This suggests that I documented the situation correctly, in that I said that it was a rolling leap second. It's not: it's a leap second that occurs somewhere in the middle of a localtime minute, and remaining seconds of that minute are numbered through 60 instead of through 59 so that there's room for the leap second. The attached patch attempts to fix this confusion too. It's true that it's tricky to compute the UTC offset in these oddball situations. But this is true regardless of whether the fix is present. I suppose that we could add wording like "the UTC offset is (deliberately) not (clearly) defined for the leap second and any later seconds in the same localtime minute". However, I think it's better to say that the leap second does not affect the UTC offset, as the attached proposed further patch attempts to do.