This thread moved me to ask a related question in a timezone
forum. It prompted several informed replies, some historical
(but not nostalgic as often happens on IBM-MAIN.):
https://mm.icann.org/pipermail/tz/2020-November/date.html
See Subject: 'What's "right"? '. (No registration required, AFAIK.)
On Fri, 13 Nov 2020 13:21:43 +0000, Rupert Reynolds wrote:
>On Thu., Nov. 12, 2020, 14:59 Peter Relson, wrote:
>
>> >> Perhaps the TOD clock is slowed or stalled for leap seconds, to keep
>> >> TOD-derived date and time in synch with solar time?
>> >>
>> >Correct.
>>
>> I'd have answered "Not correct". When the leap second change is
>> introduced, yes, this sort of thing might happen.
>> But only during that time.
>>
I disagree with both. z/OS TOD clock is unaffected; user processes
are suspended as necessary to preclude duplicate/anachronistic TIME
readings.
>> Does the OP know that their system has leap seconds in effect?
>> Does the operating system agree (what's the value in CVTLSO)?
>>
For 3.8 the answers are clearly "No."
>That's the question. I'm trying to build an understanding of the issues
>that works (for me) across the range from Hercules/MVS3.8 to recent z/OS.
>
>It seems that, if used, CVTLSO should be the gap between TOD/ETOD and UTC,
>and STCKCONV (if available) uses it to get the correct time. The only
>alternative I can see, to keep TOD valid for conversion to time & date, is
>to slow it down to close the gap, quietly forgetting the leap seconds ever
>happened.
>
I submitted an RCF for clarification of STCKCONV a couple years ago.
I got an (automated?) notification of receipt; no resolution. I'll wait
to see what the 2.5 (when?) doc says.
For rendering of archival timestamps by STCKCONV, they might be kept
in STCK minus CVTLSO form. It'll never happen; compatibility.
Do a WWW search for "leap smearing". z/OS is both the best and worst
among opsyses. Best in that the basic TOD clock follows atomic physical
time; worst for being constrained by compatibility. It's unthinkable to
adopt smearing (or UT1) by steering TOD. Smearing by thousands of
minuscule adjustments to CVTLSO would require equal thousands of
suspensions of user processes to avoid ambiguity.
>It's interesting to me because I've seen a lot of code using TOD clock
>just to display "12:25" on some report where I'd probably have let the
>system work it out for me (using TIME DEC in assembly, or some language
>feature).
>
IEBCOPY suffered the flaw in page headers until they fixed my APAR. They
DTRT by switching to TIME DEC.
>And it's interesting on a human scale, becuse there are enough leap seconds
>to get the minute wrong. "Why is your information a minute newer than mine?"
>
Even one second could get the *year* wrong at a critical boundary.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
