<snip>
"Usually" is slippery. When you need it, it's important.
</snip>
And if someone truly needs it, then they should make a business case and
submit an RFE for it.
<snip>
> and even a bad idea to save UTC time, as opposed to saving the
>STCK(E) value.
>
Why?
</snip>
Perhaps because of the lack of processing of leap seconds.
<snip>
Those data are readily available. The work is already done for you:
https://www.iana.org/time-zones
</snip>
One thing that is missing is any intrinsic knowledge of exactly where the
data was collected such as which time zone, which country, which state,
whatever.
<snip>
On Sat, 20 Apr 2013 14:39:08 -0400, Peter Relson wrote:
>... The documentation says "The STCKCONV macro converts an input
>time-of-day (TOD) clock value to time of day and date, and returns
the
>converted values to the caller in the format requested. " This is
correct
>and is complete and is all that the service can say.
>
I (and apparently you) disagree about "complete". The doc could at least
specify timezone. It seems to be, "none, rather TAI-27 seconds.)
</snip>
You continue to make this (to me) unfounded statement.
As has been mentioned before, there is no reason to talk about a timezone
in this context.
A time-of-day clock value is a time-of-day clock value. That value is
defined in PoP. Since 0 represents 1900 and since bit 51 ticks every
microsecond, bits 0-51 form a number that is the number of microseconds
since 1900.
I'd be quite happy to have the documentation clarify that the conversion
does not account for leap seconds.
Peter Relson
z/OS Core Technology Design
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
