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

Valerio Bellizzomi devbox at selnet.org
Fri Feb 9 14:37:46 CST 2007


On 09/02/2007, at 14.33, Sam Mason wrote:

>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?

Sure they do.

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

Oh yes, there are many epochs. The Julian day or Julian day number (JDN)
is the (integer) number of days that have elapsed since the initial epoch
at noon Universal Time (UT) Monday, January 1, 4713 BC in the proleptic
Julian calendar. That noon-to-noon day is counted as Julian day zero. Thus
the multiples of 7 are Mondays. Negative values can also be used, although
those predate all recorded history.
Almost 2.5 million Julian days have elapsed since the initial epoch. JDN
2.400.000 was November 16, 1858. JDN 2.500.000 will occur on August 31,
2132 at noon UT.
The Julian date (JD) is a continuous count of days and fractions elapsed
since the same initial epoch. The integralpart (its floor) gives the
Julian day Number. The fractional part gives the time of day since noon UT
as a decimal fraction of one day or fractional day, with 0.5 representing
midnight UT. Typically, a 64-bit floating point (double precision)
variable can represent an epoch expressed as a Julian date to about 1
millisecond precision.

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

There are some mathematical formula to convert from Julian to UTC and
viceversa.

>
>> [3] http://www.eecis.udel.edu/~mills/database/papers/leapseconds.pdf
>
>Unfortunately seems to have died :(

Sorry the typo, try here:
http://www.eecis.udel.edu/~mills/database/papers/leapsecond.pdf

>
>
>  Sam
>
> [6] http://tycho.usno.navy.mil/leapsec.html
>
>p.s. sorry Francois, I can't convince mutt to do Unicode




More information about the coyotos-dev mailing list