[LEAPSECS] Lets get REAL about time.
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
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