[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