In message <camzhqmnfdhk+3obrahxojxugdl7ttf6rmbofcdr-bfyhfoe...@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 [email protected] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
