On Sat, 20 Apr 2013 14:39:08 -0400, Peter Relson wrote: >>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.
I think you mean "adding 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. > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
