>I find George Kozakos's answer more satisfactory than yours. You might have found George's response "more satisfactory", but it was incorrect in a subtle way.
George wrote >It's neither. It's the STCK time where >UTC = STCK - CVTLSO >LOCAL = STCK - CVTLSO + CVTLDTO What he wrote is largely true about a time that is the result of the STCK(E) instruction in the typical case (although customers are not forced to be typical). More, there is no necessity that the input to STCKCONV have been created by such an instruction (let alone by an instruction that was recently executed). Only the creator of a time value knows its format and its intent. A given STCK-format value has a deterministic representation in date/time format. That is all that can be said. Whether it is local, UTC or GMT or came from the STCK(E) instruction is a fact unknown to the system and up to the application to decide and document to the extent its users need to know. For what it's worth, and I might be wrong about this, I thought that the clock was typically recommended to be set to UTC. And by subtracting CVTLSO from the STCK value you get to GMT, not to UTC (UTC differing from GMT by leap seconds). And you get to LOCAL by taking GMT and subtracting CVTLDTO. >There's a question here that can reasonably be asked, >and he provided a clear answer. I disagree. Because George did not answer a question that can be answered by STCKCONV. 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. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
