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

[Brooks Harris]

On 2014-01-18 03:07 PM, Eric R. Smith wrote:

> On 2014-01-18 12:02, Joseph Gwinn wrote:

>>> [POSIX time]

> ...

>>> It's defined as a transformation of a broken-down UTC timestamp, not

>>> (despite its name) as a count of seconds since some instant.

>> No.  If your poke around into how time is used, you will discover that

>> what is stored in the cound of seconds since the Epoch.  Broken-down

>> time is used only when there is a human to be humored.

> A count of "non-leap seconds" since the Epoch. That is a crucial

> difference, and it's (IMHO) the root cause of many leap second problems.

Its an *uncompensated-for-leap-seconds* Gregorian calendar counting 
scheme. I've never seen it described that way, but that's what it is.


> time_t presents itself as "elapsed time", and is frequently used that

> way, but it is not elapsed time in the usual meaning of the term (i.e.

> number of elapsed SI seconds).

>

> It's frustrating, because POSIX comes really close to providing both of

> the aspects of time (elapsed duration and civil time) that applications

> require. It wisely provides a human readable time structure (struct tm),

> and functions to convert this to and from time_t,

Its not just human readable - its a representation of time_t in YY-MM-DD 
hh:mm:ss form.


>   but then requires

> time_t to satisfy a simple formula so that the conversion between struct

> tm and time_t is fixed.

gmtime() performs a "break-down" of time_t to YY-MM-DD hh:mm:ss. Its the 
inverse of the formula defined in 4.15 Seconds Since the Epoch -

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*.


> If it just dropped that formula and required use

> of library functions to convert time_t to/from struct tm then it would

> at least be possible to implement time_t as a true count of elapsed

> seconds on a POSIX compliant system.


gmtime() will "do the right thing" (for dates after 1972) if you adjust 
time_t by Leap-Seconds-in-effect.

It gets more squirrelly when doing localtime()....

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.


>

> Alas, there are difficulties with this too -- leap seconds are

> unpredictable, and interchange of file timestamps between POSIX systems

> becomes harder. 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. Convincing some parts of the 
time-keeping community that uses POSIX and derivatives might be more 
feasible if a clear specification existed.

-Brooks


>

> Eric

>

> _______________________________________________

> LEAPSECS mailing list

> LEAPSECS at leapsecond.com

> http://six.pairlist.net/mailman/listinfo/leapsecs

>

>