[LEAPSECS] Lets get REAL about time.

Poul-Henning Kamp phk at phk.freebsd.dk
Sun Jan 22 14:04:05 EST 2012

In message <CAMzhQmNfdhk+3OBRahXojxuGdL7ttF6rmBofCdR-bfYhFOEAEg at mail.gmail.com>
, Keith Winstein writes:

>>>Isn't this a problem?


>> If it is, it's a not problem with the API, but with the way

>> leap-seconds are defined.


>Hmm, in practice I think the plan to simply fail with an error is

>going to be a non-starter.

Gee, I wonder where all these people got the crazy idea that
leap seconds could be a problem for computers :-)

> Plenty of applications need to record dates

>more than six months in the future;

They can trivially do that, but they have to do it in a format
that can represent the time.

"struct tm" can do that, (if we add frational seconds to it as
I proposed)

But time_t and realtime_t can not, because they are scalar and
the scalar number of seconds between any epoch and UTC timestamp
more than 6 months out in the future, is undefined.

>Perhaps you envision a whole other, separate API for representing and

>validating EDT (and other civil time, and UTC) timestamps

That's what "struct tm" is for, it records the timestamp on
"broken down" format, including the timezone.

>The notion that "the API" can do nothing more than report an error

>message is not quite right. There are some alternatives:


>1) Ignore leap seconds when converting future EST/EDT/UTC-specified

>moments into a timestamp.

ENOCANDO, if we define a new API to deal with leap-seconds, it has
to deal with leap-seconds correctly.

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.

More information about the LEAPSECS mailing list