Brooks Harris said:
> tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
> (tm_year???70)*31536000 + ((tm_year???69)/4)*86400 ???
> ((tm_year???1)/100)*86400 + ((tm_year+299)/400)*86400
>
> This is an *uncompensated-for-leap-seconds* Gregorian calendar counting
> scheme with an artificially imposed "1970" ("the Epoch") "origin". I
> like to call it the 1970 *barrier*.
Why is it a barrier? Nothing prevents tm_year being negative; indeed, it's
a signed type.
> But, CAUTION - not all implementations of gmtime() are equally good.
> I've compiled and tested many versions from the open-source community
> and many have smoking gun errors. Outright bugs don't help confidence in
> consistent implementation and contribute to the confusion.
And that's *without* having to test for an event that only happens every
year or two. Which is why software engineers (among others) would like to
get rid of leap seconds.
>> Maybe the way forward would be to introduce a new
>> "elapsedtime_t" type that really does count seconds since the Epoch (to
>> be used in any applications that require duration) and to deprecate
>> arithmetic on time_t values (which is problematic around leap seconds).
>
> Yes, generally. Getting ANSI c and POSIX standards bodies to change
> their ways is an uphill battle.
When I was on the ISO C (*NOT* "ANSI c") committee, we looked at the issue.
Then we asked the expert community (that is, you lot), to come up with a
consensus proposal that we could look at. As far as I know, the committee
is still waiting.
(I *did* get the double leap second error removed from ISO C, meaning it
vanished from POSIX as well. Everyone agreed that this had been a simple
misunderstanding of something back when the first version of the C Standard
was being written.)
--
Clive D.W. Feather | If you lie to the compiler,
Email: cl...@davros.org | it will get its revenge.
Web: http://www.davros.org | - Henry Spencer
Mobile: +44 7973 377646
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
