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

[Michael H Deckers]

    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
    saying that
        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.

    Michael Deckers.