[coyotos-dev] coyotos.sleep, sleepTill, the epoch

[Sam Mason]

On Thu, Feb 08, 2007 at 07:59:08PM +0100, Valerio Bellizzomi wrote:
> On 08/02/2007, at 16.14, Sam Mason wrote:
> >The Wikipedia entry fails to mention when this change could occur.  As
> >far as I can tell the proposal is to change it in 2022[1,2], not much
> >help for Coyotos.
> 
> Sam:
>   Thanks for the references, I give you some other [3,4,5].

They cast the net pretty wide don't they?

>   TAI and other time scales have been used for long time. Julian Dates
> have been used for centuries by astronomers, geodesists, and other science
> people.

I've been doing lots of time related reading over the past couple
of days, interesting subject to get a bird's eye view of.  Lots of
strangeness like POSIX time starting 1970-01-01T00:00:00 UTC when UTC
wasn't properly defined until a couple of years later.  Or even worse,
Microsoft saying that their time (also UTC) starts in 1601, begging the
question of how many leap seconds there were between 1972 and then.

>   Which time scale you need depends upon which applications you run.
> Implementing other time scales is useful independently of the change in
> 2022.

I was going to say something about the kernel using TAI, but while I was
fiddling around with the references I forgot what I was really writing
about!  I found an interesting comment in[6] saying:

  It is recommended by the BIPM that systems which cannot handle
  leapseconds use TAI instead.

As Francois says, it's reasonably easy (only a table small lookup and
integer addition) to covert from TAI to UTC, something that could be
done in user-space.  Going the other way would require the kernel
to maintain a listing of the currently specified leap seconds and
interrogate this list during (most?) time related code.

> [3] http://www.eecis.udel.edu/~mills/database/papers/leapseconds.pdf

Unfortunately seems to have died :(


  Sam

 [6] http://tycho.usno.navy.mil/leapsec.html

p.s. sorry Francois, I can't convince mutt to do Unicode