But the average installation with NTP / ETR running UTC would not even have to that, would they? NTP will pick up the extra second, and ETR will find the hardware clock ahead of time and slow it down for 8 hrs to align with the new wall clock time: UTC incl leap seconds. If you'd schedule the 1 second correction on the HCP for that moment, the resulting clock would appear by magic to match the wall clock and your hardware clock remains to run on AT.
Rob On 10 January 2015 at 15:18, Peter Relson <[email protected]> wrote: > >And IBM provides no way to do that correctly. > > Care to elaborate? > > The documented process when leap seconds are specified is to schedule the > leap second change via the STP panels to occur at the published time. That > way the z/OS UTC time remains accurate. When the +1 leap second update is > processed we spin for 1 second to ensure there are no duplicate UTC time > stamps. > That seems pretty correct to me. > > If you're referring to formatting the date/time from a time stamp and not > taking into account just when a leap second (or a daylight savings time) > change occurred, I agree that that is what happens (and in practice I > suspect you'd be unlikely to be able to make a business case that doing so > is either needed or would be worth the increased path length). > > Peter Relson > z/OS Core Technology Design >
