On 2014-01-18 11:39 PM, Clive D.W. Feather wrote:
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.
Depends on the implementation. Some code has a 1970 constant and goes
stupid in the negative. Extricating that from implementations of
gmtime(), localtime() etc can be a pain.
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.
I'm *not* one those software engineers who want to "get rid of leap
seconds". Leap Seconds is one of those things we expect computers to
help us with. I think its the lack of clarity in standards and legacy
behavior in computer systems that has confused the issue. Yes, the
testing is a challenge, but not insurmountable.
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've seen some proposals from Markus Kuhn and others. I haven't reviewed
them in detail. I gather they were rejected?
Yes, that's the challenge - to get a proper specification through
due-process.
(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.)
Good work!
-Brooks
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
