[LEAPSECS] stale leap second information

Rob Seaman seaman at noao.edu
Sat Jan 17 16:55:09 EST 2015


On Jan 17, 2015, at 1:51 PM, Steffen Nurpmeso <sdaoden at yandex.com> wrote:

> Maybe it would be sufficient to start at 2014, which would avoid counting months of 42 years

However the data are encoded, stored or retrieved, there will be a concept of operation that supports a variety of timekeeping / calendar use cases.  These surely include historical / retroactive requirements.  Any implementation should support the entire table of leap seconds.

In message <89326.1421483072 at critter.freebsd.dk>, "Poul-Henning Kamp" writes:

>> 11 bits for Month is good until 2142
>> 
>> 7 signed bits for TAI-UTC, if leaps continue at the "traditional"
>> 18-36 month rate, are good for 40-80 years. 

Unless there is an overriding value in efficient encoding, should such limits be built in at the beginning?  There's a lot more room for whatever features in IPv6.  What are the advantages of v4 versus v6?  Disadvantages of v6?

Rob



More information about the LEAPSECS mailing list