On Wed, 29 Oct 2025 01:22:18 -0500, Mike Schwab <[email protected]> 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
