On Jan 12, 2012, at 07:09, John Gilmore wrote: > This is my last post on this topic. Diominishing returns have clearly set in. > I guess it's left for someone else to follow up.
> Hardware STCK[E] values obtained directly do not contain leap seconds; > other software-mediated time and date values do usually reflect them. Does this even include the STCK(E) variants of the TIME macro, or does it return the raw value stored by STCK? If the latter, why bother? Error recovery? And consider the scenario: 1. On June 30, at 23:59:59.99... I invoke the TIME macro. 2. System code issues STCK 3. A leap second occurs; the OS spins for 1 second, during which it adds one second to CVTLSO 4. After the spin ends, system code fetches CVTLSO and subtracts the value from the STCK result. 5. After conversion, TIME returns 23:59:58.99... to my program. Oops. A second off. It might even violate monotonicity relative to an earlier call to TIME at 23:59:59.50. This could be prevented by fetching CVTLSO both before and after STCK and retrying if they differ. An uncomfortable overhead to avoid error that can occur only every few years. > The leap-seconds table in the PrOp provides the information, not quite > up to date in the current edition, needed for this software mediation. > FSVO "not quite up to date". It includes the last previous leap-second, on January 1, 2009, so it won't become actually out of date until June 30, 2012. -- gil
