e already live in a
world with more than one time scale, except that the fact that more
than one time scale exists is often papered over and/or neglected.
(And that is when problems start to surface.) Perhaps this could be
documented (or refuted) more carefully, while avoiding ambi
better than that.
-Tim Shepard
s...@alum.mit.edu
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
date to a new
revision of the NTP protocol, then you could presumably update the
system to no longer depend on the difference between UTC and UT1
being bounded.
-Tim Shepard
s...@alum.mit.edu
_
earth minute", and "earth second"?
Seems a nice parallel to "mars day", "mars minute", and "mars second"
that was used by JPL for the probe missions.
And instead of "universal time", we can call the earth-tracking tim
> * definition: UTC-1972-day - a duration either 86400 SI-seconds or
> 86401 SI-seconds long
or 85999
> * leap-seconds are added to UTC-1972 with the aim of keeping UT1 and
> UTC no more than 0.9 SI-seconds apart
Leap seconds may be inserted or deleted, though so far there have only
been insert
econds over 10 years.Leap seconds are in the noise compared
to errors due to accumulated drift of standalone machines.
If it has a way of receiving a time signal to stay synchronized, then
it ought to have a way of receiving info about the leap seconds (if
they even matter).
p seconds, then the difference
between UTC and what time it is will grow (slowly) without bound.
(If you need to know what time it is with precision and accuracy better
than +/- 1 second, then it is already surprisingly complicated.)
-Tim Shepard
flashing "aproximate" or
"estimate" indicator next to the display which flashes for the
first 20 minutes or so until it has received a complete copy of the
almanac.
-Tim Shepard
s...@alum.mit.edu
__
need to understand your system better than a POSIX spec could
possibly inform you, and I don't think neglecting to maintain UTC (by
neglecting to insert leap seconds as needed to keep it within +/- one
second of the correct time) would change tha
gt; long those years were.
Oh that is easy. A year is however long it takes a tree ring to grow.
-Tim Shepard
s...@alum.mit.edu
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
I got my copy of _American Scientist_ in the mail yesterday and didn't
flip through it until this afternoon.
What a nice article on pages 312 through 319!
-Tim Shepard
s...@alum.mit.edu
___
LEA
8a619d17c4935c3320d2ef9e92bdeed05d
but the patch didn't get deployed everywhere it needed to be deployed,
and the wedge up of some web site server farms made news:
http://www.wired.com/wiredenterprise/2012/07/leap-second-glitch-explained/all/
ere's some inconsistency in your ascii art for the box
that just adds to the confusion.
-Tim Shepard
s...@alum.mit.edu
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
not a big
deal, and just leave it pointed at c49.leapsec.com. until
c50.leapsec.com can be created. Users just need to understand that
when fetching next.leapsec.com it may be pointing at a leap second (or
lack of leap second) that has already happened.
later doesn't become broken if changes like
that happen some day.)
-Tim Shepard
s...@alum.mit.edu
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
#x27;s notion of the time was off
by a few seconds (if not tens or hundreds of seconds). If some
important system cannot handle a leap second without disruption, then
perhaps we should be worried about what else it can not handle, or how
brittle the system is to begin with.
-Tim Shepard
s...@alum.mit.edu
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
ut some
(like Warner's) seem better (more straightforward) than others.)
-Tim Shepard
s...@alum.mit.edu
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
17 matches
Mail list logo
