On 2017-11-19, at 10:45:24, Charles Mills wrote:
>> Subtract?
>
> Sort of. My impression -- and I would be happy if someone could definitively
> confirm or correct me -- is that leap seconds are of course subtracted from
> the TOD value, but the value in CVTLSO is negative, so adding CVTLSO
> subtracts the leap second count. On the test LPAR that I am currently
> looking at CVTLSO is zero, so that's not much of a clue.
> http://www.longpelaexpertise.com/toolsTOD.php supports my thinking.
>
There I see:
To get a correct UTC value, you need to add 'leap seconds' to the TOD
clock value. This number of leap seconds for the current time is
stored in the CVT field CVTLSO.
which I'll regard as some combination of ambiguous and uninformed
Looking for IBM sources I find APARs such as
http://www-01.ibm.com/support/docview.wss?uid=isg1OA14831
The correct value for leap seconds as of 12/31/05 is 23 seconds.
CVTLSO = 00000015EF3C0000 = 23 seconds
Positive, so subtract
...
converting the value in CVTLSO to seconds and
subtracting from the LOCAL time
>> how does one ensure that CVTLSO hasn't changed
>
> I don't know. How DOES one change CVTLSO? I just searched MVS System
> Commands and Init & Tuning for <leap> and <CVTLSO> and got no hits.
> Specifically, is there a supported way of changing it "suddenly"?
>
If you wait long enough the HMC will change it for you. And it's
sudden, and may be at an inopportune time.
> Google reveals that you and I had this same discussion a year ago:
> https://www.mail-archive.com/[email protected]/msg59183.html
>
> A more significant issue IMHO is that CVTLSO is the *current* leap second
> adjustment. If one is converting a timestamp from ten years ago -- say from
> an archived SMF dataset -- how does one get the leap second offset at that
> time? If it changes between STCK and AG or between the start of some job and
> its end, then at worst one is off by one second. Adjusting a TOD from 2007
> by today's offset will put you off by four seconds. For a TOD (real STCK or
> "computed") from 1971 you will be off by almost half a minute.
>
https://en.wikipedia.org/wiki/Tz_database
> Yeah, LE *could* support negative UNIX times. Would not take a great
> algorithmic leap. But the fact is that they don't.
-- gil
