> On Jan 16, 2015, at 3:37 AM, Tony Finch <[email protected]> wrote: > > $ dig +short leapsecond.dotat.at aaaa | sed 's/:6:/:06:/' | sort > 1972:06:30::23:59:60 > …. > 2012:06:30::23:59:60 > 2015:06:30::23:59:60
I’m *loving* this. I think this would make the problem of “these damn NTP servers are lying to me, or some of them are, who do I believe” when some NTP servers light up the leap second bit and others don’t. Servers can use it to cross check the data the reference clocks are giving them. Clients can use them to sort out source of truth to determine the truthiness of a given NTP servers information. It will also allow you to leverage DNSSEC to get all the security inherent in that. Oh wait :) Or you could sign the data with a public key that BIPM could publish so the data can be validated as authentic, though that only works if there’s a convention for getting the signature for some canonical representation of the data. Also like the convention of :58 to publish the last second of the month. While not strictly a leap second, this tells the time code the exceptions to the length of month in the current UTC timeline. In fact, you could actually make the lookups easier if you leveraged the domain system. <month>.<year>.lastsec.utc.int would be the lookup. Wildcard entry for 23:59:59 would be present. positive leap seconds would get a 23:59:60 entry, negative ones would get a 23:59:58 entry. This data format is compact and could have extremely long TTLs so it could be cached very efficiently locally. Bad thing about compact data, though, is that it is much harder to sign since there’d only be two different signatures making the spoofing problem an issue. DNSSEC could solve that issue. This could also be trivially extended to DUT1 where monthly, or even daily, DUT1 measurements could be published by looking up increasingly specific numbers. <hour>.<day>.<month>.<year>.dut1.utc.int and you look up the precision you need, with a generic current.dut1.utc.int for the latest estimate. This would also give people a transition method off of UTC in the future should that become necessary for people that need to know earth orientation. People building earth orienting instruments today could use this data stream, plus UTC with the explicit expectation that |DUT1| might exceed 1s and this data can be used to compensate. Given the long lead times involved, though, I don’t imagine this would happen on a scale measured in anything less than decades :(. Warner
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
