On Fri, 28 Dec 2018 14:46:41 -0500, Peter Relson wrote:
>I shouldn't have included "TIME" among the services I mentioned because
>that's "current", not "historic" (so only has to deal with "current" leap
>seconds) and because it does not let you choose STCK as the "zone" -- you
>
Not as the "xone", but as the format.
>must choose between local and UTC, both of which are defined with respect
>to leap seconds.
>
>Thus it must handle leap seconds, but also is not in the position of
>needing update for a "new" leap second.
>
I believe STP does this magically, in CVTLSO. And user tasks are paused,
magically, during a leap second. PoOps has tables of leap seconds, almost
up-to-date. That's what TNLs used to be for.
>And, in case you're wondering, at the "instant" of bringing in a new leap
>second, there are various approaches in play that customers choose to
>adopt and I doubt that it is deterministic on which side of the fence you
>would necessarily fall if you used some service such as TIME (or if you
>did it yourself) -- perhaps the STCK was done "just before" but reference
>to CVTLSO was "just after". Something similar could happen with respect to
>time zone offset changes.
>
Does TIME protect against this improbable occurrence? Remember Murphy!
I can imagine only:
RETRY: copy CVTLSO and CVTLDTO into private storage
STCK
compare copied values to CVTLSO and CVTLDTO
BNE RETRY
proceed with conversion
Does TIME do something similar? Does STP serialize updates to CVTLSO
and CVTLDTO? Does TIME use STCK or STCKF? Does this reload cache
for the compare if necessary?
Suspending user tasks during leap second doesn't help.
Remember Murphy.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
