[LEAPSECS] Bulletin C and all that
brooks at edlmax.com
Mon Jan 26 17:05:25 EST 2015
On 2015-01-26 04:34 PM, Tom Van Baak wrote:
>> I spent many weeks this year frantically trying to head off exactly this
>> problem in a standards body defining a timing protocol. It had been
>> written to insert Leap Seconds "at midnight", which we know from Rec 460
>> is not correct.
> Please make sure the word "insert" is never used. That fails for the case of negative leap seconds. Perhaps use "apply" or "implement" or "introduced" or other words that are positive/negative neutral.
Yes, I agree.
> Some HP products avoid words altogether and simply report how long the last second of the current month will be: 59, 60, 61 seconds.
Unfortunately many protocols provide mechisims to transport metadata
like that, but do not specify how to populate it. And, of course, most
all fail to even consider communicating historical Leap Seconds table or
"local time" parameters. Rob Seaman's prototype DNS format is a good start.
> While you're at it, make sure the words June and December are also never written into the standard. Only IERS gets to pick the month, and everyone one else follows what they tell us.
Agreed. Its really easier to implement "end of (any) month". Checking
for June and December just risks bugs and is not comprehensive anyway.
> That goes for code, tables, scripts, standards, man pages, etc. We can assume with near-term modest earth rotation rate offsets that IERS will pick June and December, but as the offset grows then March and September, and then other 8 months are fair game as well. So if you want a standard to be robust, please avoid any hard-coded reference to "preferred" months. Note that the current "6 month" advance warning is also not set in stone so no one standard should ever depend on that either.
ITU Rec 460 says "2.3 The IERS should decide upon and announce the
introduction of a leap-second, such an announcement to be made at least
eight weeks in advance.".
IERS seems to be trying for 6 months (more is better if it doesn't
confuse people or implementations), but they might not be able to
achieve that always. This is where the standards need to be clarified,
where IERS (probably) needs to *promise* to do whatever is agreed on,
and where ITU-R should define how its to be disseminated.
Again, Rob Seaman's prototype DNS format is a good start and might
provide a model that could be recommended to some standards body.
In an earlier email I suggested a "time metadata API". Maybe I should
have used the work "interface". My point is to define the metadata
format and services (like, say, "GetMostRecentLeapSecondInfo()") in a
generic manner. This then would provide the common normative reference
for other implementation standards on various platforms (Linux,
Windows, embedded, c, POSIX, java) and through various transmission
channels (binary, character, internet, radio...).
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
More information about the LEAPSECS