[LEAPSECS] Lets get REAL about time.

[Poul-Henning Kamp]

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.