[LEAPSECS] Common Calendar Time (CCT) -Brooks Harris

[Brooks Harris]

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