[tz] [PROPOSED] Fix ambiguous leapsecs by rolling up to a minute
eggert at cs.ucla.edu
Sun Sep 12 23:42:40 UTC 2021
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
>> + 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...
Size: 3174 bytes
Desc: not available
More information about the tz