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

Eric R. Smith ersmith at hfx.eastlink.ca
Sat Jan 18 18:07:49 EST 2014


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.
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, but then requires
time_t to satisfy a simple formula so that the conversion between struct
tm and time_t is fixed. 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.

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

Eric



More information about the LEAPSECS mailing list