[LEAPSECS] Lets get REAL about time.

[Poul-Henning Kamp]

In message <CAMzhQmM18E8ssh3PRT+Jz3_hvraPiEWyxt4Yti47LFCUjxnBsw at mail.gmail.com>
, Keith Winstein writes:

>On Sat, Jan 21, 2012 at 7:44 AM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:

>

>> libc will need an updated table of leap-seconds to give you UTC,

>> and if you hand it a timestamp that is more than some set delta-T

>> from the last entry in the leapsecond table, it will return E2BIG

>> rather than give you a potentially wrong timestamp.

>

>My concern is with this part of the proposal.

>

>You are saying that if the time given is more than six months in the

>future, realtime_tm() will simply return an error and will not be able

>to produce a human-readable timestamp (whether in UTC, EST, EDT, CET,

>BST, etc.).


Correct, if we don't have the knowledge to do it, we fail the conversion.

You can create any UTC timestamp you want at any point in history
where it is defined.

But you can only convert that UTC timestamp to a realtime_t (and
vice-versa) for timestamps where the conversion is defined.

UTC is only defined approximately 6 months in advance, and that is
an interesting point for implementors of this API.

Bulletin C 42 came july 8th 2011 and says "until futher notice"
Bulletin C 43 came january 5th 2012 and says "until futher notice"

It seems to be like "6 months less one week" notice.

Since leapseconds can happen in any month, I guess that gives us a
validity window to 7 months, less 8 days from the the last recorded
bulletin-C.

That again, tells us how fast we have to distribute leap-second
lists: we have less than three weeks, from we receive Daniel Gambis
email.


>Isn't this a problem?


If it is, it's a not problem with the API, but with the way
leap-seconds are defined.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.