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

[Valerio Bellizzomi]

On 07/02/2007, at 17.37, Jonathan S. Shapiro wrote:

>On Wed, 2007-02-07 at 23:29 +0100, Valerio Bellizzomi wrote:
>> On 06/02/2007, at 23.22, Jonathan S. Shapiro wrote:
>> 
>> >On Tue, 2007-02-06 at 23:45 +0100, Valerio Bellizzomi wrote:
>> >> 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?
>
>Since we don't report uptime, we don't track it anywhere. There is no
>notion of counting uptime at all. I'm confused by the question.

Why are you confused?  is there any means to know how long the machine has
been up ?

>
>> > 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."
>
>The critical words in that quote are "non-conforming".

It is non confirming if you want to strictly conform to POSIX. But for
what concerns hard real-time and some scientific applications, the
critical words are "Time values from these systems do not suffer the
ambiguity that strictly conforming POSIX systems or NTP-driven systems
have."

If I want to conform to another time scale, where in the code I need to
make changes ?

>
>> "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."
>
>For better or worse, UTC is universally used, and we need to adopt it.

Of course I understand and agree. In the future it will probably change to
be like TAI, without leap seconds, I consider this to be an open question
as the topic is being broadly discussed.

val