There is an architectural definition of what a tick in bit 51 of the 64-bit TOD clock. Thus a given clock value (bits 0-51) represents the number of microseconds since the start of the epoch being used. It seems true that STCKCONV assumes the standard epoch. As I said, if that is not mentioned in the doc, I'd be in favor of doing so.
A STCK value came from the clock and is not to be considered UTC time. Why then should STCKCONV which is converting an input STCK value (not an input UTC value) provide a UTC date/time? If you want to provide a UTC clock value, then you could presumably do so. Should the service(s) factor in leap seconds? It no longer matters. They could not be changed to do so, since it would be incompatible. They could be enhanced to do so with a new non-default option but there would have to be a business case for that, and at this point no one has come close to making one. Therefore the thing to do is to document the current behavior, for which I've already said that I'm OK with indicating that this does not factor in leap seconds. I think Gil indicated he had submitted, or would submit, an RCF. As far as I know, none of the BCP-provided time services (TIME, STCKCONV, CONVTOD, BLSUXTOD, etc) pay attention to leap seconds. Nor are they likely ever to do so, if only because no one wants to have to update them whenever a leap second "shows up". If you want a service that does something with a historical time stamp and leap seconds, make the case. It hasn't been made in all the years since the first leap second. Maybe that's because humans don't truly need to know that level of precision for "old dates". Is this discussion similar to the question about "local time"? I don't see many people trying to factor into a display of time/date from a historical time stamp just when day light savings kicked in or out. I think local time is considered to be for humans and that it is thought that humans can "deal with it". 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
