[LEAPSECS] POSIX Time

[Magnus Danielson]

M. Warner Losh wrote:

> In message: <4AD0A3D9.2080403 at rubidium.dyndns.org>

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

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

> : 

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

> : 

> : I had the distinct memory that we discussed this indepth some time ago 

> : both on and off list(s).

> 

> Yes.  The original time_t (and long before it) definition was a bit

> vague.  It was written as "Seconds since Jan 1, 1970 GMT," but in

> practice it either had so large an error that the exact definition was

> irrelevant, or it was implemented as POSIX time_t is today.


The initial systems used the 60 Hz or 50 Hz of the power grid.


> POSIX is worse.  You'd think you could display the leap second by

> setting a struct tm's tm_sec to 60, but POSIX specifies that this

> value be normalized before display, so you get the first second of the

> next day twice if you don't roll your own routines...


There are ways in which the POSIX could be extended to allow for propper 
time, but time_t would probably have to stay the same. The POSIX time_t 
fits the needs of embedded systems or various servers and clients having 
no need for propper UTC, but when you need it you need to look further, 
and that would also result in the need to correct all related 
applications. But then, that is the price one needs to play since time_t 
is neither TAI or UTC.

Cheers,
Magnus