[coyotos-dev] coyotos.sleep, sleepTill, the epoch
Jonathan S. Shapiro
shap at eros-os.com
Wed Feb 7 16:37:05 CST 2007
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.
> > 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".
> "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.
--
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100
More information about the coyotos-dev
mailing list