On Thu, 29 Oct 2015 11:03:09 -0400, Peter Relson wrote: > >If you want to format "now", then you can use TIME. And you can ask that >the output be provided in one of many formats, including LOCAL and GMT/UTC >(each of which has a definition of how it is calculated from the current >clock value, where GMT's and UTC's definitions are the same). > Thanks.
There might be a practical use here. It appears that STCKCONV provides a greater variety of output formats than TIME (am I right?) So a programmer might use a TIME; CONVTOD; STCKCONV sequence to get one of those other formats. Just slightly convoluted. >... it could be a "future" time (up to a limit >which I think in the most current z/OS release is the end of the 2nd >epoch). > I tried this. 2.1 gives: 2185-06-04 23:47:34.740991; fails on 1.13. And adding one jiffy fails on 2.1 also. >It is true that leap seconds are not taken into account in the >(close-enough-for-human-consumption) STCKCONV or CONVTOD processing. If >you would like a statement in the book that that is the case, we would >likely agree to do so. > There's an example in the Reference of "9FE4781301ABE000", an apparently "random 8-byte value", which converts to 1989-02-19 05:24:13.942462. But the Reference doesn't show any result. (It seems to agree with your chronology of STCKCONV. Perhaps a developer did STCK and pasted the output into the Reference.) I might suggest as an alternative a string from the Principles for the July, 2015 end of leap second 26: "CF2D54B4FBA80000", and output of the example, "000026000000000020150701", formatted as "2015-07-01 00:00:26.000000", and a statement that this shows that leap seconds are not taken into account. RCF material? Thanks again, gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
