On Jan 17, 2015, at 1:51 PM, Steffen Nurpmeso <sdao...@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.1421483...@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 _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
