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.