[LEAPSECS] POSIX Time (was WP7A)

[Magnus Danielson]

Joe Gwinn wrote:

> Magnus,

> 

> At 5:10 PM +0200 10/10/09, Magnus Danielson wrote:

>> Joe,

>>

>> Joe Gwinn wrote:

>>> At 3:28 PM +0200 10/10/09, Magnus Danielson wrote:

>>>> M. Warner Losh wrote:

>>>>> In message: <4ACFF759.3090903 at rubidium.dyndns.org>

>>>>>             Magnus Danielson <magnus at rubidium.dyndns.org> writes:

>>>>> : M. Warner Losh wrote:

>>>>> : > In message: 

>>>>> <13205C286662DE4387D9AF3AC30EF456AFA8697A05 at EMBX01-WF.jnpr.net>

>>>>> : >             Jonathan Natale <jnatale at juniper.net> writes:

>>>>> : > : AFAIK, routers also just re-sych.  The OS's are not capable of

>>>>> : > : xx:xx:60 time.  For reading router logs this is fine in most 

>>>>> cases

>>>>> : > : which is all NTP is really for.  I don't think they simply 

>>>>> step the

>>>>> : > : time, I am pretty sure they do tweak the freq.  I could be 

>>>>> wrong and

>>>>> : > : I am NOT representing Juniper here, just my thoughts. :-)

>>>>> : > : > FreeBSD will cope with the xx:xx:60 second correctly, 

>>>>> assuming it is

>>>>> : > told about the leapsecond soon enough.  Not all other parts of the

>>>>> : > system can cope with the xx:xx:60, but that's a posix time_t

>>>>> : > limitation that you can't do anything about[*].

>>>>> : > : > Warner

>>>>> : > : > [*] The 'right' timezone files attempt to do things 

>>>>> correctly, but in

>>>>> : > doing so they break time_t definition...

>>>>> : : I assumed you meant to say that it breaks the POSIX time_t 

>>>>> definition.

>>>>>

>>>>> Yes.  The most current time_t definition is the one codified by POSIX.

>>>>> Older standards are fuzzier about what time_t really means.

>>>>

>>>> Indeed. As there exist several time_t definitions, I wanted to make 

>>>> sure you was refering to the POSIX mapping of UTC time into time_t, 

>>>> which forms an "interesting" timescale of its own, almost but not 

>>>> close enough to UTC.

>>>

>>> By definition, POSIX Time is closer to TAI than to UTC, but in 

>>> practice time in POSIX-compliant computers is usually NTP steered to 

>>> approximate UTC (most common) or to GPS System Time (where 

>>> leapseconds cannot be tolerated).

>>

>> As the text of subclause 4.14 of the POSIX base standard defines it, 

>> it is based on "Coordinated Universal Time" and the "name" is mapped 

>> into seconds as defined by the mapping function. This makes it follow 

>> UTC while maintaining the mental feel of being TAI-based without any 

>> leap seconds, but it is closer to UTC as only occasionally (on the 

>> leap second second) differs by a second during a second while it has a 

>> so far constantly increasing difference to TAI. So on average it is 

>> much closer to UTC than TAI.

>>

>> So I respectfully disagree with your statement that POSIX Time is 

>> closer to TAI than UTC. I think that it is closer to UTC and that the 

>> NTP steering honour the POSIX UTC to time_t mapping.

> 

> Be careful to distinguish "broken down time" (an ascii string that 

> resembles UTC) from the underlying clock (two 32-bit integers that are 

> supposed to count SI seconds and nanoseconds since the POSIX Epoch).


This is why I write "POSIX time_t" rather than "POSIX time" to start 
with, to indicate that I mean the integer number value.


> If you read the POSIX standard, you will find that the length of the day 

> is defined as exactly 86,400 seconds, no more no less.  So, leap seconds 

> are by definition forbidden.  This was the intent of the committee.


I fully recognice this fact and see the POSIX time_t to be defined in 
such a way, yes.


> Another common source of confusion is that the POSIX Epoch is an instant 

> defined in UTC terms, but one can define an instant in any timescale one 

> wishes, and the instant may appear in all of them but belongs to none of 

> them.


You can use any timescale of choice, but the definition actually brings 
in UTC explicitly, and that is not a random timescale. Had the selection 
been TAI (or a suitable shift of it) it would have solved alot of 
problems, as relative measures between time_t would work well and 
absolute time stamps througout would be consistent and the issue of 
leapseconds would be hidden in the presentation into broken down time as 
libc performs it. If the text was not using the wording relating to UTC 
the issue would be quite different.


> However, most people who care even a little about time use NTP to 

> synchronize their computer's time to something, and by far the bulk of 

> the relevant timeservers publish UTC, never mind the formal definition 

> of POSIX Time.  So, in practice time on such systems is neither fish nor 

> fowl, being neither TAI not UTC, instead being a mixture.


NTP honour the UTC to time_t mapping. It does not give the correct 
23:59:60 reading thought, as the POSIX time_t system does not allow that.


>> A user wishing to display correct UTC time during leap-second would 

>> need to querry the NTP  kernel over the provided interface to recover 

>> the extra information, which is possible when the NTP has the 

>> necessary leapsecond information and is enabled.

> 

> A tall order for sure, and one is completely at the mercy of the 

> operating system kernel developers, who may be hazy on the details of time.

> 

> In the systems I have had a hand in, the computer clocks are 

> synchronized to GPS System Time (because those systems cannot tolerate 

> the discontinuities caused by leap seconds) and UTC is made by the 

> application software only where needed when needed.


That will work. I have no trouble with using a continous scale at the 
core, it just happends to be that I don't intereprent the POSIX time_t 
definition to provide that, it provides to me a time which looks 
continous, but there is occasional hickups if you follow the definition.

To be clear, within the POSIX time_t system, days is exactly 86400 
seconds long, and within that context broken down time and compound time 
is consistent. The problem lies in how the defined mapping from UTC to 
time_t is done, as the UTC broken down time (still) includes leap 
seconds. The UTC reading 23:59:60 will be a legal UTC name which still 
needs to be converted into POSIX time_t and when it is, the 00:00:00 
second occurs twice. This is what the definition means, as POSIX can't 
rule out the legal UTC leap second readings.

If you don't care about the fuzziness about not knowing which of these 
two seconds something happend or that a time-difference over a leap 
second may become 1 second longer than intended, then configuring an NTP 
client or hooking a GPS receiver with UTC will not be much of a deal.

Trouble is when systems needs correct time from ground up and also needs 
to follow propper UTC. Then you need to repair it from ground up.

If the core time was say GPS time based (still maintaining the POSIX 
epoch at or near 1970-1-1 00:00:00 GMT/UTC, the GPS epoch is a decade 
later) then broken down time would need to make leap second corrections, 
but that would work fairly well, as time_t would be strict 86400 second 
based but actually count the leap-seconds properly.


>> I had the distinct memory that we discussed this in depth some time 

>> ago both on and off list(s).

> 

> You've let our secret out!  Yes, it was in January 2009.


Right. Not meant to expose you or any ideas in a bad way. Sorry.

Cheers,
Magnus