On Tuesday, 04/12/2016 at 03:56 GMT, Glenn Knickerbocker <n...@bestweb.net> wrote: > Rod Furey wrote: > >> General question: what happens if you say "at 01:59 do this" then at 02:00 > >> the clock goes back to 01:00? > > On 4/9/2016 3:16 PM, Rob van der Heij wrote: > > That will have popped already. i don't think you expect me to wake you > > twice. > > What if it never did? DELAY is waiting for 01:59, but then suppose > COMMAND calls a program that runs from 01:30 DST to 01:30 Standard Time. > How do we know whether the clock changed before or after 01:59?
But here's the trick: The machine doesn't wait until a "time". It waits until the TOD clock is .GE. the value in the TOD CLOCK COMPARATOR. Neither the TOD nor the TOD CLOCK COMPARATOR are affected by DST changes. And if you use STP, the TOD clock will appear to slow down slightly for about 7 hours when a leap second is introduced. In case no has ever said it explicitly, computers don't know what time it is. They can't. It's a man-made construct that we use to measure the *passage* of time. "It's not a thing." So we teach computers how to do "+1" on a precision basis, and we assign an arbitrary time to the value of zero. To quote from the PrinOps: In converting to or from the current date or time, the programming support must take into account that leap seconds have been inserted or deleted because of time-correction standards. When the TOD clock has been set correctly to a time within the standard epoch, the sum of the accumulated leap seconds must be subtracted from the clock time to determine UTC time. So if you want to set the TOD CLOCK COMPARATOR to a UTC-based time value (e.g. local time), the program that sets it must take into account any TZ boundaries that will be crossed and the leap seconds that will be included in that value *in the future*. IMO, accurate UTC-based time values should be limited to 6 months in the future since that's as far in advance as we know leap seconds. (Technically it's 3 months, but who has the time to worry about that?) The issue in CMS is that it doesn't have or use any of the TZ or leap second data, so when you use its interfaces to set timers, it assumes that there is no TZ offset change and no leap second to worry about. This is what was confusing Gil about my previous statements. When we set the TOD clock "to UTC" we're actually setting it to a value that correlates to UTC, but on the standard epoch. The TAI bias he referred to is a bit of a red herring, a factoid only needed if you care about TAI. UTC = TAI - 10 - leap seconds. TOD = TAI - 10. So UTC = TOD - leap seconds, again confirming what the PrinOps says above. (It's a wonder Einstein's head didn't explode.) However, if you place the CPC on a vehicle that is approaching the speed of light.... This is pertinent to any discussion of Personal Time Zones (PTZ). DST boundaries are crossed at (e.g.) 02:00 *in your local time zone*, so CPC location isn't relevant. It's everywhere and nowhere. Alan Altmark Senior Managing z/VM and Linux Consultant Lab Services System z Delivery Practice IBM Systems & Technology Group ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott
