On Fri, 14 Sep 2018 08:08:14 -0400, Peter Relson wrote:
>There is nothing in error with any of the conversion services. They do
>what they intend to do. And yes they do the easy part. What there is is a
>lack of functionality that would usually be unimportant to have.
>
"Usually" is slippery. When you need it, it's important.
>... it is generally a bad idea to save local time,
>
Yes. Someone should tell ISPF.
> and even a bad idea to save UTC time, as opposed to saving the
>STCK(E) value.
>
Why?
>Sure, a service could be provided to convert a time stamp to one that
>subtracts out the value corresponding to the leap seconds at the
>particular time.
>That service would have to be updated every time a leap second is added
>which wouldn't be a big deal, but is work to do.
> ...
>And that would only help for STCK(E) <--> UTC. Exactly when a time zone
>offset change occurred is unknowable in general, so trying to figure out
>the true local time based solely on a STCK(E) value cannot be done;
>additional data would be needed.
>
Those data are readily available. The work is already done for you:
https://www.iana.org/time-zones
>As to this statement
>>z/OS shirks by shutting down user tasks during that second.
>"Shutting down user tasks" is not true in general that, but can be true
>depending on your time protocol.
>
I understand that "shutting down user tasks" is part of the protocol IBM
recommends.
>For the case where it is true, it should be apparent that no other
>approach could possibly work in order to accommodate dependencies upon
>timestamps to determine the sequence of events.
>
False. The UTC specification deals with that by requiring the value
23:59:60.xxx during a leap second. The sequence of events is
well-determined.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
