[LEAPSECS] Bulletin C and all that

[Rob Seaman]

On Jan 26, 2015, at 5:23 AM, mike at lumieresimaginaire.com wrote:

> Le 26.01.2015 07:00, Rob Seaman a écrit :
> 
>> Have also started experimenting with DUT1 encoding, which is some amalgam of the other three bulletins (predictions versus retroactive computations versus severely rounded values on uneven calendar gridding). At any rate the 5 decimal places from Bulletin A fit neatly into a 20-bit int as at the bottom. The idea would be to index into the entries via the explicit YYYYMM in the name. One might imagine interpolating (linear, spline, whatever) between dates.
> 
>  Why stick at MM values? IERS give us DD predictions on a weekly basis.
> 
>  Great work Rob. I don't think interpolating is a good idea as IERS might do better than a weekly distribution in the future.

You have answered your own question - IERS may directly improve on this.  Similarly a DNS mechanism isn't a replacement for the proposed tzdist leap second support.  The issue is how much functionality to try to fit into DNS.  It would be pretty simple to build a web service off the latest IERS Bull. A:

	http://datacenter.iers.org/eop/-/somos/5Rgv/latest/6

A couple of pages of python could parse that file and provide a reasonably complete ICD.  (And presumably many have done this.)

But it doesn't make sense to try to squeeze Berners-Lee through DNS.  Rather DNS provides high reliability and low latency for small quantities of focused information.  As I said, the experiment has just started with DUT1 information.  Whether the case will be as clear-cut for this information as for Bull. C is not obvious yet.  For one thing Bull. D takes effect on random dates not at the end of a month.  Also whether functionality wants to be client-side or server-side, etc.  DNS wants to remain lightweight.

> IMHO this is more important than having leap second data distributed via DNS as it would mean that we could easily create a UT1 driver for NTP and go to UT1 for a legal time distribution service which wouldn't need fiddling with in the future.

There are more fundamental issues to resolve with that, e.g., UT1 is only known retroactively.  The predictions can change with each Bull. A.  That said, the predictions are very good.  But there is no reason that NTP needs to wait on our DNS explorations.

On the other hand a few carefully chosen DNS-mediated entries could provide useful validation for more fully featured services moving forward.  For instance, a way to check on whether locally cached values need to be updated.

Rob