[LEAPSECS] Coming of age in the solar system

[Ian Batten]

On 5 Sep 2010, at 08:12, Poul-Henning Kamp wrote:


> In message <2475FDE1-9FA3-4116-B382-442351702ED5 at noao.edu>, Rob  

> Seaman writes:

>> On Sep 4, 2010, at 6:59 AM, M. Warner Losh wrote:

>

>> Ten years in just imagine where we could have been if we hadn't

>> misspent the entire decade advocating or trying to bat away this

>> relentless ITU temporal blitzkrieg, but rather were focusing on

>> building consensus for a coherently engineered system...

>

> I don't remember ever seeing even a hint of a plan for how you plan to

> get POSIX/OpenGroup standards updated and enforced.


Does Posix say much about how time is handled, beyond providing  
interfaces to get and set it and to mess about with representations?    
 From the 2008 draft:

> The gettimeofday() function shall obtain the current time, expressed  

> as seconds and microseconds since the Epoch, and store it in the  

> timeval structure pointed to by tp. The resolution of the system  

> clock is unspecified.

>


time() has similar wording.

A strict reading of that (assuming seconds means SI seconds and  
"since" means elapsed) is probably TAI(now) - TAI(epoch): it's an  
elapsed measure, so from 23:59:59 to 00:00:01 should be three seconds  
in a leap second case, while in Posix it will only be only be two.

But:


> The gmtime() function shall convert the time in seconds since the  

> Epoch pointed to by timer into a broken-down time, expressed as  

> Coordinated Universal Time (UTC).


Which means that gmtime (to yield UTC) needs to understand the  
leapseconds that time() doesn't return - otherwise gmtime(time()) is  
going to return UTC including leap seconds up to 1 Jan 1970 but not  
beyond (or some similar botch).

Which is why, as someone pointed out upthread, its standard practice  
in database land to use select now, because it's better to be  
consistently vague than inconsistently vague.

Given the way Posix systems are currently implemented, the assumption  
is made that leap seconds are applied as a correction.  Which means  
that time() doesn't meet its contract (because time() is short by the  
number of leap seconds by 1970) in order to make gmtime work  
correctly.   Saying that change requires fixing the Posix standards is  
a little disingenuous: they're already broken, and stopping issuing  
further leap seconds doesn't undo that broken-ness.

ian