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

[Valerio Bellizzomi]

On 06/02/2007, at 23.22, Jonathan S. Shapiro wrote:

>On Tue, 2007-02-06 at 23:45 +0100, Valerio Bellizzomi wrote:
>> On 06/02/2007, at 2.45, Jonathan S. Shapiro wrote:
>> 
>> >Neither.
>> >
>> >The "epoch" is not defined in the spec, but it is similar to the UNIX
>> >epoch. Time starts at midnight on Jan 1 1970. See the wikipedia
article:
>> 
>> Yes it is clear, but this not what I meant. I meant "uptime" which
>> obviously starts somewhere in system bootstrap.
>
>Where are you seeing this in the spec? I don't think that the interface
>reports uptime anywhere.

I see uptime nowhere in the spec.
The question is: where in system bootstrap uptime starts counting?


>
>> 
>> >
>> > http://en.wikipedia.org/wiki/Unix_time
>> 
>> The relevant part of this discussion is:
>> 1. If the TAI-based variant is used, we can divide unix time by 86400,
>the
>> result is number of days since epoch. Because TAI has no leap seconds,
it
>> follows the Resolution B1 of IERS (see:
>> http://www.iers.org/MainDisp.csl?pid=98-110),
>> 2. Use 64 bits signed integer data type to represent unix time numbers,
>> this fixes the Year 2038 problem.
>
>We are using 64 bit quantities.

Good choice.

> We are NOT using TAI (which is busted).

What the heck!  I don't understand why you say that TAI is busted. Perhaps
UTC and civil time are busted. Leap seconds are artificial and busted.
Quoting http://en.wikipedia.org/wiki/Unix_time  :

"Another, much rarer, non-conforming variant of Unix time keeping involves
encoding TAI rather than UTC. Because TAI has no leap seconds, and every
TAI day is exactly 86 400 s long, this encoding is actually a pure linear
count of seconds elapsed since 1970-01-01T00:00:00 TAI. This makes time
interval arithmetic much easier. Time values from these systems do not
suffer the ambiguity that strictly conforming POSIX systems or NTP-driven
systems have."

and

"As of 2004, the possibility of ending the use of leap seconds in civil
time is being considered. A likely means to execute this change is to
define a new time scale, called "International Time", that initially
matches UTC but thereafter has no leap seconds, thus remaining at a
constant offset from TAI. If this happens, it is likely that Unix time
will be prospectively defined in terms of this new time scale, instead of
UTC. Uncertainty about whether this will occur makes prospective Unix time
no less predictable than it already is: if UTC were simply to have no
further leap seconds the result would be the same."


val