[LEAPSECS] Bulletin C and all that
Rob Seaman
seaman at noao.edu
Tue Jan 27 07:51:21 EST 2015
Tom and I seem to keep the same (early) hours...
On Jan 27, 2015, at 4:49 AM, Tom Van Baak <tvb at LeapSecond.com> wrote:
>> But there have been real bugs due to leap indicators remaining set too
>> long, leading to bogus leaps at the end of July. So in practice there is
>> less risk in allowing leaps only in June and December.
>
> Those real bugs are better fixed at their source than worked around in this manner. Ok, easy to say and hard to do, I know.
The issue is policy versus implementation. The standard allows the end of every month, so any implementation (whether DNS or otherwise) should do likewise. The IERS June / December policy is appropriate for the current epoch - i.e., oversamples the UTC "waveform" - so only some of the months permitted by this encoding will correspond to leaps.
One could argue - and many of us on this list did - that a better policy would be to issue a leap second every month, alternating plus and minus. Introducing a positive leap second would be to omit a negative one. This would make sure the leap code worldwide was well exercised and maintained. That is not the current policy, but the encoding would support it. If I had a time machine I might make a side trip to convince the old boys of that:
http://media.npr.org/assets/img/2015/01/25/tomtoro02_custom-72d86a0f1d2051eaeebdb97cc5ce2edbdf1f7533-s1200.jpg
> Perhaps leap indicators should not be booleans but small wrapping integers. For example GPS makes use the low order 8 bits of the week number for almanac version checks. Perhaps the same could be done for leaps, especially if they are encoded as a TAI offset integer instead of +/- yes/no booleans.
If the two flags in my suggested encoding ("negative?" and "leap?") are concatenated they are the same as PHK's 2-bit signed 2's-complement integer.
> Another approach is to stop distributing leap seconds as a monthly flag and instead issue a yearly set of 12 values. That way not only does everyone gets the leap schedule a year in advance but no years or months get special treatment. The TAI-UTC leap second tables simply grow by one line per year.
Or like Bulletin A which announces a year in advance every week. Prior discussions have suggested that UT1 is well-modeled enough to predict leap seconds 2-3 years (or maybe a bit more) in advance. The modeling has improved dramatically since leap seconds were introduced, it is perfectly reasonable to consider implementing a new policy. The current TF.460 standard permits this, and the proposed DNS encoding can publish information for a given month whenever it becomes available.
> Also, Rob, et al, did you consider sorting your tables down instead of up? That is, put 1972 at the bottom instead of the top.
DNS doesn't care about order. The table is just a result of iterating over the different domain names in the client python script. See appended, with range(26,0,-1) instead of range(27). (And the final of the five values in the "Decoded" columns is the same as PHK's example - I concatenate the separate flags to make the same 2-bit int internally for the offset.)
> Most people want to know the current year and not the entire history.
We don't have to choose between supporting most people and all people. Each use case can correspond to a different "method". PHK wants "bulletin-c.leapsec.com" (or more likely his own trusted domain). This corresponds to just that, whether the bulletin announces a leap second or not. Somebody else might need only the latest / pending leap seconds, called "latest.leapsec.com". Etc.
These two methods happen to correspond at the moment:
bulletin-c.leapsec.com -> 250.10.36.152 -> OK 2015 7 36 1 (1, 0)
latest.leapsec.com -> 250.10.36.152 -> OK 2015 7 36 1 (1, 0)
But they will presumably differ when Bulletin C50 is announced.
Rob
--
YYYY MM before after encoded crc IP Decoded flags
--------------------------------------------------------------------------------
leap26.leapsec.com -> 250.10.36.152 -> OK 2015 7 36 1 (1, 0)
leap25.leapsec.com -> 249.230.35.254 -> OK 2012 7 35 1 (1, 0)
leap24.leapsec.com -> 249.188.34.161 -> OK 2009 1 34 1 (1, 0)
leap23.leapsec.com -> 249.152.33.233 -> OK 2006 1 33 1 (1, 0)
leap22.leapsec.com -> 249.68.32.220 -> OK 1999 1 32 1 (1, 0)
leap21.leapsec.com -> 249.50.31.138 -> OK 1997 7 31 1 (1, 0)
leap20.leapsec.com -> 249.32.30.45 -> OK 1996 1 30 1 (1, 0)
leap19.leapsec.com -> 249.14.29.193 -> OK 1994 7 29 1 (1, 0)
leap18.leapsec.com -> 249.2.28.21 -> OK 1993 7 28 1 (1, 0)
leap17.leapsec.com -> 248.246.27.9 -> OK 1992 7 27 1 (1, 0)
leap16.leapsec.com -> 248.228.26.174 -> OK 1991 1 26 1 (1, 0)
leap15.leapsec.com -> 248.216.25.124 -> OK 1990 1 25 1 (1, 0)
leap14.leapsec.com -> 248.192.24.127 -> OK 1988 1 24 1 (1, 0)
leap13.leapsec.com -> 248.162.23.128 -> OK 1985 7 23 1 (1, 0)
leap12.leapsec.com -> 248.138.22.40 -> OK 1983 7 22 1 (1, 0)
leap11.leapsec.com -> 248.126.21.129 -> OK 1982 7 21 1 (1, 0)
leap10.leapsec.com -> 248.114.20.85 -> OK 1981 7 20 1 (1, 0)
leap9.leapsec.com -> 248.96.19.154 -> OK 1980 1 19 1 (1, 0)
leap8.leapsec.com -> 248.84.18.147 -> OK 1979 1 18 1 (1, 0)
leap7.leapsec.com -> 248.72.17.6 -> OK 1978 1 17 1 (1, 0)
leap6.leapsec.com -> 248.60.16.129 -> OK 1977 1 16 1 (1, 0)
leap5.leapsec.com -> 248.48.15.2 -> OK 1976 1 15 1 (1, 0)
leap4.leapsec.com -> 248.36.14.76 -> OK 1975 1 14 1 (1, 0)
leap3.leapsec.com -> 248.24.13.158 -> OK 1974 1 13 1 (1, 0)
leap2.leapsec.com -> 248.12.12.208 -> OK 1973 1 12 1 (1, 0)
leap1.leapsec.com -> 248.6.11.133 -> OK 1972 7 11 1 (1, 0)
and/or:
c49.leapsec.com -> 250.10.36.152 -> OK 2015 7 36 1 (1, 0)
c48.leapsec.com -> 242.4.35.72 -> OK 2015 1 35 0 (0, 0)
c47.leapsec.com -> 241.254.35.218 -> OK 2014 7 35 0 (0, 0)
c46.leapsec.com -> 241.248.35.51 -> OK 2014 1 35 0 (0, 0)
c45.leapsec.com -> 241.242.35.151 -> OK 2013 7 35 0 (0, 0)
c44.leapsec.com -> 241.236.35.228 -> OK 2013 1 35 0 (0, 0)
c43.leapsec.com -> 249.230.35.254 -> OK 2012 7 35 1 (1, 0)
c42.leapsec.com -> 241.224.34.48 -> OK 2012 1 34 0 (0, 0)
c41.leapsec.com -> 241.218.34.63 -> OK 2011 7 34 0 (0, 0)
...
More information about the LEAPSECS
mailing list