On Mon, 2021-09-13 at 13:38 +0000, Michael H Deckers via tz wrote:
Isn't it quite simple to compute the fictitious local time LT: when UTC is 1972-06-30T23:59:59Z then LT is 1972-07-01T01:23:44 1972-06-30T23:59:60Z then LT is not well-defined 1972-07-01T00:00:00Z then LT must be 1972-07- 01T01:23:45 so as to keep the offset at 01:23:45 from UTC 1972-07-01T00:00:14Z then LT must be 1972-07- 01T01:23:59 1972-07-01T00:00:15Z then LT must be 1972-07- 01T01:24:00
In your proposal, LT - TAI and UTC - TAI have discontinuities at different values of TAI so that LT - UTC just cannot be constant.
Michael Deckers.
Rather than have Local Time be not well-defined, wouldn't it be better to have it well-defined all the time, even though that causes the GMT offset to change for a few seconds? If the rule is that the local time minute that includes the leap second has 61 seconds, numbered 0 to 60, then we have this: when UTC is 1972-06-30T23:59:59Z then LT is 1972-07-01T01:23:44 1972-06-30T23:59:60Z then LT is 1972-07-01T01:23:45 1972-07-01T00:00:00Z then LT is 1972-07-01T01:23:46 so the GMT offset becomes 01:23:46 from UTC 1972-07-01T00:00:13Z then LT is 1972-07-01T01:23:59 1972-07-01T00:00:14Z then LT is 1972-07-01T01:23:60 1972-07-01T00:00:15Z then LT is 1972-07-01T01:24:00 and the GMT offset is back to 01:23:45 from UTC This has the benefit that LT is always well-defined and each second of UTC has a corresponding name in LT, and all LT seconds have unique names. This means that conversion between UTC and local time is always possible and is reversible. The down side is that the GMT offset is not constant, but that is only true for a few seconds near the leap second. John Sauter (John_Sauter@systemeyescomputerstore.com) -- get my PGP public key with gpg --locate-external-keys John_Sauter@systemeyescomputerstore.com