[LEAPSECS] POSIX Time (was WP7A)

[Magnus Danielson]

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

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.

Cheers,
Magnus