Time Libraries Rough Draft

[Seth Kurtzberg]

Ketil Malde wrote:

>Seth Kurtzberg <seth at cql.com> writes:
>
>  
>
>>>Yes, because TAI is a clock, not a calendar.
>>>      
>>>
>
>  
>
>>We are getting bogged down in the terminology here.  
>>    
>>
>
>I've tried -- but am happy to try again -- to propose:
>
>     clock : something that measures the passage of time,
>             unit is seconds
>
>     calendar: something that deals with the passage of time
>               with other units -- hours, minutes, years, dates
>
>I guess one reason this is not a simple and useful distinction is that
>people prefer POSIX' time, where the second count is computable from
>the UTC calendar alone (and vice versa), and thus a POSIX "second"
>(a "psecond"?) is sometimes two SI seconds, and sometimes none.
>
>I think it is desirable that a clock has good accuracy, while it is
>less of a problem if a calendar is wrong -- new year celebrations
>nonwithstanding. 
>
>  
>
>>My problem is that, as proposed, the library will give wrong answers.
>>    
>>
>
>The problem is wanting a one-to-one correspondence between the
>clock (counting seconds) and the calendar (describing other time
>entities, like hours or dates).
>
>POSIX is AFAIK the only way to handle this, and it is done by changing
>the definition of "second".  A POSIX clock (unlike an SI-seconds based
>one) will of course only be able to keep time correctly or calculate
>correct durations (as SI seconds) if has access to leap second
>tables.  
>
>The advantage of POSIX is that you don't need the leap second table to
>calculate the UTC calendrical presentation of time.  Well, most of the
>time, anyway -- it won't work *during* a leap second, I guess.
>
>If you store the time to new year as SI seconds, you will have the
>problem of leap seconds, even if you use UTC -- you will need to know
>whether 2005-12-31T23:59:60 exists or not.  (Or you can go the .NET
>route, which just pretends it is an error.)
>
>And of course, accurate time depends on distributing leap second
>tables anyway, as you need to know when to slow down the POSIX clock. 
>
>  
>
>>Having a nanosecond granularity library that can't even manage one
>>second accuracy doesn't seem useful to me.
>>    
>>
>
>We would be in good company.  With all the legacy baggage, it is
>rather utopian to expect computers to be able to deal sensibly with
>leap seconds for the foreseeable future.
>
>  
>
>>I can't see the logic in a library that returns incorrect answers,
>>because to return correct answers is more difficult.
>>    
>>
>
>Accurate timekeeping really isn't that important for computers.
>  
>
As a general statement, that's absurd.  The computer is just a machine.  
Timekeeping is crucial for certain applications, which happen to be the 
ones I work on.  You simply can't do many things without accurate 
timekeeping.  Orbital determination is the most obvious, but it's 
equally important to get something into orbit in the first place.  If 
you ignore the realities of time (that is, that the universe isn't much 
interested in our simplifications) you get your satellite in the wrong 
place, and you lose $100 million.  For the people who are spending the 
$100 million, that's important.

It is extremely easy to lose track of a LEO satellite due to a one 
second error, and to not find it before it shuts itself down and allows 
itself to burn up in the atmosphere.

It may be true that applications for which time is important are not 
common.  Then, if we don't care, why are we writing a time library at 
all?  If it doesn't matter, don't do it.  If it's worth doing, don't 
return the wrong answer.

The universe doesn't stop for that period when POSIX pretends that it 
does.  Given the choice of reality or POSIX, it seems to me that reality 
is a more sensible choice.

For these projects that I mentioned, we rewrite the timekeeping 
functions for every new project.  That is exactly what a library is 
supposed to avoid.  Exactly of what use is the library that gives the 
wrong answer?  If you want the same answer that is already available in 
the C library, you can use the FFI and call the methods in the C library.

Reinventing a wheel is bad enough.  Reinventing a broken wheel can't be 
the right thing to be doing.

>-kzm
>  
>