In a recent note, David Andrews said: > Date: Thu, 10 Nov 2005 09:01:43 -0500 > > Slightly OT but an interesting thing I just noticed: our MVS console > reports the following time in response to a "D T" command: > > IEE136I LOCAL: TIME=08.46.20 DATE=2005.314 GMT: TIME=13.44.27 > DATE=2005. > 314 > > We're in the U.S. eastern time zone, five hours offset from GMT. You'll > notice that my local time isn't exactly five hours offset from the TOD > clock -- this is because the TOD clock drifts over time (we don't have > an ETR) and we adjust the local offset every week to compensate. > If you're forced to this deceit, would it be better to chisel on the value of the Leap Second offset? This would presumably get both GMT and LOCAL correct, while leaving IAT (who uses it?) incorrect.
> I just noticed that in a Unix shell, the time is apparently derived as a > hardcoded five-hour offset from the TOD clock: > > # date > Thu Nov 10 08:44:27 EST 2005 > > So it ~appears~ that the Unix environment (or at least the "date" > command) doesn't use the CVTTZ (or CVTLDTO) offset. > It can be set by each user (actually each process) by setting the TZ environment variable. And I assume the "date" command uses not the raw TOD clock content, but first applies the Leap Second offset from the CVT, then the TZ-derived value. Or perhaps it applies TZ to the result of a TIME(GMT) macro call. > Maybe this is aparable? Or do I have a configuration error? > I've repeatedly ranted that there should be a single setting that controls both Classic and the default for z/OS Unix (when TZ is unset). Since the UNIX conventions are more sophisticated and general, this should employ UNIX facilities, perhaps to load CVTTZ and CVTLDTO, not the other way around. Try your APAR; keep the pressure up. And more recently, most UNIX systems rely on a hierarchy of parameter files (an extension to POSIX). These get the time offset correct for October, 1972, e.g.; where z/OS Unix gets it wrong. If logging timestamps are to be kept in UTC and converted to local time for display, this sort of historical correctness is necessary. And history will become more recent when/if the date of the semiannual time change is legally modified in 2007. -- 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
