On Thursday, December 29, 2005 at 22:54:20 +0000, David L. Mills wrote: > You really should read the commentary in the NIST leapsecond file
Thanks for the hint. Latest leap-seconds.3331497600 comments: | The following entry specifies the expiration date of the data in this | file in units of seconds since 1900.0. This expiration date will be | changed at least twice per year whether or not a new leap second is | announced. And the important dates in order are: | Last Update of leap second values: 28 July 2005 | [latest positive leap in table] 1 Jan 2006 | File expires on: 28 June 2006 > The file does not expire when the leap is inserted; it remains valid > as a record of past TAI offsets until the next edition is issued. Better than that: An issue remains completely valid until just before next still uncertain event opportunity. > When multiple valid sources display conflicting leap bits, the logical > OR of these bits is used. Currently one leap=01 source wins the consensus over any number of leap=00 sources. That's fine, because many sources don't carry leap bits at all. But that can be fooled, if the leap=01 source is wrong. Seen here reports of this HP Zsomething, or that Truetime GPS, anouncing leap or leaping themselves at a wrong date. The NIST file could win consensus until expiration, making sure no spurious leap second announcement is done. Serge. -- Serge point Bets arobase laposte point net _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
