On Wed, 29 Oct 2025 18:16:21 -0500, Mike Schwab wrote: >So far there has not beeb a negative (backward) leap second and due to the >problem of repeating a second there is a proposal to ban negative leap > The terminology is challenging. A leap second which makes a day one second longer by setting the clock backward is called a positive leap second. A leap second which makes a day one second shorter by setting the clock forward is called a positive leap second. <https://en.wikipedia.org/wiki/Leap_second> The leap second facility exists to provide this adjustment. The lea p second was introduced in 1972. Since then, 27 leap seconds have been added to UTC, with the most recent occurring on December 31, 2016.[1] All have so far been positive leap seconds, adding a second to a UTC day; while it is possible for a negative leap second to be needed, this has not happened yet.
The positive leap second is the more troublesome one because it can result in clocks appearing to move backwards and duplicate tine stamps. >seconds in the future, just wait until you need a positive (forward) leap >second. > That would be a *negative* leap second. Although safer, it will cause problems because of inadequate testing. CvTLSO was set to 0 in 1972. It now contains 27 seconds in TOD format and is *subtracted* from TOD to produce UTC. See PoOps "TOD Programmable Register" for more. >On Wed, Oct 29, 2025 at 10:56 AM Paul Gilmartin > wrote: > >> On Wed, 29 Oct 2025 01:22:18 -0500, Mike Schwab wrote: >> >> >One feature is that some sites use different times in different regions. >> >I. E. a Japanese, Indian, European, Eastern US, Western US time zones. >> All >> >implemented with different offsets from UTC. And IBM spreads leap seconds >> >over the affected minute. >> > ... >> The practice is called "Leap Second Smearing". I can find no good >> reference. >> I hope that correction is made at midnight UTC everywhere, not local. >> I understand that both Google and Amazon servers do it with different >> smearing durations. >> >> It couldn't be done by TOD clock steering. >> o I believe the maximum steering rate is a second in several hours, >> not just a minute. >> o It would contradict the statement in PlOps that TOD is kept at >> TAI minus 10 seconds. >> Is it done by repeated minuscule adjustments to CVTLSO? >> >> It was discussed here a few years ago that: >> o Before a leap second all user processes are made nondispatchable. >> o During the leap second 1 is added to CVtLSO. >> o after the leap second user processes are dispatched. >> >> That leaves a hazard that if CVtLSO is accessed and >> STCK is issued on opposite sides of the leap second, >> in either order, there is a possibility of: >> o Invalid UTC >> o Duplicate UTC >> o anachronistic UTC. >> That can be avoided by such as: >> Try: fetch CVTLSO >> SGCK >> compare CVTLSO to value previously fetched >> BNE Try >> Ugh. Two extra instructions executed a million times daily >> to cover a pitfall that can occur at most twice a year, is >> unlikely, and impossible to recreate for problem reporting. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
