On 06/28/2014 05:19 PM, Paul Gilmartin wrote: > On Sat, 28 Jun 2014 15:21:04 -0500, Joel C. Ewing wrote: >> An uncomfortable thought: If the vendor product in question is saving >> timestamps with inconsistent conventions, have you verified that it is >> indeed consistently using the correct offset to derive the UCT value > >from local time and the the change in offset values actually occurs at >> the proper local time? >> > Ouch! Ouch! Ouch! If the vendor derives UTC from local time, he's > probably Microsoft. Fire him! For reasons well discussed earlier in > this thread, conversion from local to UTC is unreliable. Rather the > basis should be UTC and local tim derived from that. > > Here, IBM wisely chose to run the TOD clock on UTC (give-or-take > CVTLSO) and derive GMT and LOCAL in the TIME macro from that. > > -- gil > Ouch indeed! Yes, I see that's what I wrote! I was thinking of potential inconsistencies between UCT and local time and got my thoughts backwards.
In the z/OS environment it's not the UCT values that are questionable (assuming TOD is set to the correct convention), it's the offset to local time and local time that may be suspect. My point, which I hope might still have come through from the rest of my paragraph, is that an application cannot totally depend on changes to the z/OS system local time offset from UCT to determine whether Daylight Saving time should be in effect, or depend on system local time values to be consistent with the official DST transition rules. This is because the local time transition on z/OS may depend on some manual action (like an IPL), or even on an automatic process where there is some potential for the process to run too far from the precise time it should. z/OS and its current hardware have the capability of automating this process with great precision, but there may be historic or application reasons why installations may require that other events determine the precise time of transition. The discrepancy may be short lived and the window of opportunity only occurs two days a year, so any level of imprecision here may be inconsequential in the context of interest, but yet the imprecision may exist. -- Joel C. Ewing, Bentonville, AR [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
