[tz] [PROPOSED] Fix ambiguous leapsecs by rolling up to a minute

[Paul Eggert]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Improve-wording-about-ambiguous-leapsec-fix.patch
Type: text/x-patch
Size: 3174 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/tz/attachments/20210912/92643683/0001-Improve-wording-about-ambiguous-leapsec-fix.patch>