Magnus Danielson magnus at rubidium.dyndns.org
Tue Oct 13 03:44:57 EDT 2009

Steve Allen wrote:

> On 2009 Oct 12, at 03:27, Zefram wrote:

>> The number appears again in the main text:


>> As represented in seconds since the Epoch, each and every day

>> shall be accounted for by exactly 86400 seconds.



> Clearly that number is fiat, and not even some entity with the

> authority of Pope Gregory could change it. What remains is primarily

> to interpret the meaning of the word "day".


> In the time scales for TAI, LORAN-C, GPS, and now BST the word "day"

> already has a meaning more clearly communicated by "atomic day".

> The length of that "atomic day" is practically equivalent to the

> "ephemeris day" of Gauss, as codified by Newcomb, as adopted by IAU,

> and as realized by Markowitz, Essen, et al.


> Resolution V of the 1884 International Meridian Conference defines

> "day" to be a mean solar day. To propose that "day" become redefined

> as an "atomic day" is to propose the abrogation of the IMC. It is

> plainly outside the scope of the POSIX committee to implement such

> a change. They have to rely on the providers of time to give a

> clear indication of what time_t should try to count.

The POSIX time_t day of 86400 seconds is kind of sacred. It is however a
loose concept as the actual seconds of a day can be 86401 without too
much fuzz for most apps, but the trouble is that applications that care
needs to store the leapsecond counter with each timestamp in order to
separate a timestamp occuring on a leapsecond from occuring the second
before the timestamp. If the application cares about timestamps of
files, then it depends on a rather large rewrite of the operating system
to do the right thing. Thus, using broken down time in UTC to forcefeed
time_t has complications to it. Letting time_t instead represent TAI has
the issue of the timekeeper now must be able to provide TAI or GPS-time
(which isn't TAI, but TAI-like) along with leapsecond data for UTC. That
would mean the end of many GPS receivers being in use today, but change
of a POSIS machine would be less for those that care, the TAI to UTC
conversion can occur as a presentation factor just as with timezones.

So, letting time_t be TAI based and provide means for TAI to UTC
conversion (for those vendors that care to provide it and those
operators that include it) would work.

Boxes without external steering would not know if they where doing TAI
or UTC stylish times... but the operator wouĺd have set them to whatever
suitable and they would tick away not bother about the details.

NTP based UTC forcefeeding of today would not use feed the leapsecond
offset which would remain at 0 and the conversion would do the right
thing. Updated NTP would decide if it can splitt the time, and when it
can, it would feed the time_t in TAI and leapsecond offset with correct

Two boxes running different setups receiving an event and time-stamping
them would not set the same time_t value, but broken down time could be
made the same between the boxes. However, the error would be 30 some
seconds off. Applications which needs to display this difference would
need to bring the leapsecond offset in to compensate.

Sure, the time_t would only nominally be TAI-based (it would never be
THE TAI), but would kind of work.


More information about the LEAPSECS mailing list