[tz] [PROPOSED] Fix ambiguous leapsecs by rolling up to a minute
Michael H Deckers
michael.h.deckers at googlemail.com
Sun Sep 12 21:18:23 UTC 2021
On 2021-09-12 00:36, Paul Eggert via tz proposed:
> + Fix localtime misbehavior involving positive leap seconds in a
> + timezone with a UTC offset that is not on a minute boundary.
> + (No such timezone exists in tzdb, luckily.) Without the fix,
> + the timestamp was ambiguous during a positive leap second.
> + With the fix, the localtime leap second appears at the end of the
> + localtime minute containing the UTC second just before the UTC
> + leap second, which means leapseconds roll slightly in these
> + oddball timezones. 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):
> + 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
I disagree with that proposal.
Above all, the comment should make it clear that the
proposal only affects the behavior for the "right" system time,
that is, when system time is an approximation of TAI - 10 s
(rather than one of UTC, as required by POSIX).
Even in this infrequent case, and even though the proposal
would not have an effect for any time scale currently described
by tzdb (because the offsets from UTC are all integral multiples
of minutes since 1972-05), the proposal does not represent any
civil time scale definition that is likely to be decided
in the future. In fact, such time scales will undoubtedly
be specified as
UTC plus or minus an offset
(perhaps with GMT or similar wording instead of UTC).
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.
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, not by
T01:23:45. I have never seen a local time scale definition
the offset from UTC is +01:23:45 except between
a positive leap second in UTC and the next full
minute in local time, where the offset is 1 s greater;
and I do not expect to ever see one. The proposal would
also introduce a difference between the local times determined
with the "right" data, and those determined with time2posix()
and the normal data.
So even if the proposed change is applied, I think it is
very unlikely to ever take an effect, and in that unlikely
case, the effect likely will not be a desired one.
Not a software change I find useful.
More information about the tz