On Jan 22, 2015, at 3:27 PM, Steffen Nurpmeso <sdao...@yandex.com> wrote:
> One of them is that the count of months start 2014 not 1972, which > extends the representable range of years until 2099. Prior leap seconds don’t vanish - nor do prior Bulletins C. There certainly may be retroactive use cases that rely on this mechanism. It is much cleaner and more robust to support the entire history of leap seconds. > And the other adjustment was that the base drift now is 9-bit, not > 8-bit, still signed though, reaching from -255 to +255. There really is no need for a negative tally. The mechanism needs to support the possibility of an occasional negative leap second, but the geophysics argues against getting three dozen of these in a row, especially not right off the bat. The longer the string of positive leap seconds go on, the harder it will be to force it negative in any physically realistic way. > And here i simply reduced that from 2-bit to a single bit, stating > wether it is a positive leapsecond. Only if a leapsecond occurs > the DNS record will be updated at all, so it really makes no sense > to store more than a single bit. Bulletin C is issued whether or not a leap second occasion (currently June and December, but could be any month) corresponds to an actual leap second. The encoding (as in PHK’s example) should be able to represent a positive, negative or absent leap second. > Well. PHK follows the IERS format which uses the 1st of the month > after the leap second, i.e., the second after the leap occurred. This is an implementation detail. PHK’s choice is as good as the other. > With 2 bits for > a day number (X - 28) the exact date of the leap second could be > collected from the record without any further calculation. According to TF.460 it will always be the last day of the month. Rob _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
