In a recent note, Rob Scott said: > Date: Tue, 26 Sep 2006 15:20:45 -0400 > > (1) You have a STCK value in a field in a control block value > (eg a "created" date) > (2) You want to display that in local time > (3) Instinct prompts the developer to add the doubleword value > CVTLTDO to the STCK value and then use STCKCONV to format it nicely > Sometimes instincts are not to be trusted. CMS SENDFILE makes such a blunder converting timestamps in local time to GMT for transmission. I wouldn't be surprised if TSO TRANSMIT does likewise.
> Unless the software maintains some sort of country+timezone+date lookup > table to adjust the TOD value before calling STCKCONV you could end up > being a hour or more out in the displayed local time. > You left out Leap Seconds. It should not be the application's responsibility to "adjust the TOD value before calling STCKCONV"; rather that adjustment should be performed by STCKCONV itself. It's conceptually wrong to think of semiannual "DST Changes". Rather there should be a subroutine that takes as an argument any TOD clock value, past, present, or (with limitations) future and returns the corresponding local civil time. John G. might even agree with me on this point. On some UNIX systems, I can supply a GMT in mid-October 1971 to localtime() and it returns the (Colorado) local time with a -7 hour offset, because at that time DST ended in early October. I can supply a GMT in mid-October 2006 and it reflects a -6 hour offset because nowadays DST ends in late October. Such a subroutine could be updated today to account for 2007 and (presumably) beyond. z/OS Unix Services isn't so clever. It should be. STCKCONV is even stupider. It should be smarter. Alas, UNIX doesn't do leap seconds; forbidden by POSIX; always uses UTC. -- gil -- StorageTek INFORMATION made POWERFUL ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
