If I were in charge (no chance), I would go with exactly TWO different versions of a time stamp on z/OS. A binary one, which "just happens" to be identical to the output of the STCKE instruction (16 bytes, 128 bits). And a character one which is the full ISO8601 format ( yyyymmddThhmmss.sssss+hh:mm ). And some system function which translates between the two. I don't really know if 5 digits after the decimal point is the "best" precision. And the + is a + or - and is based on the offset kept in the CVT. While I'm at it, the default TZ in LE and UNIX, if not specifically set, should also be assumed to be the equivalent of what the offset is in the CVT.
On Fri, Oct 25, 2013 at 9:16 AM, Paul Gilmartin <[email protected]>wrote: > On Fri, 25 Oct 2013 08:50:53 -0500, Donald Likens wrote: > > > > > >TMECVTD > > +0 00000000 08670000 10182013 00000000 > > > >The time is not correct (the date is). Any ideas on what I am doing > wrong? By my calculations the time should be 14:52:00.16. > > > Since IBM refuses to document the behavior of STCKCONV (they > say it should be "common knowledge" in response to my RCF), > it's pretty hard to say any result is right or wrong. > > And it has been discussed here that among various SMF record > types there are radically different conventions for representation > of the timestamp. Some argue that this is proper given radically > different requirements for range, precision, and API among those > various various record types. I'm unmoved by the argument. > > -- gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
