On Mon, 15 Jan 2007, Peter Bunclark wrote:
http://www.eecis.udel.edu/~mills/ipin.html
That page does not seem to mention UTC...
Look at the slides.
Tony.
--
f.a.n.finch [EMAIL PROTECTED] http://dotat.at/
BISCAY FITZROY: VARIABLE 4, BECOMING SOUTHWESTERLY 5 TO 7 IN NORTHWEST
FITZROY.
On Mon, 8 Jan 2007, Steve Allen wrote:
Don't forget that UTC and TAI are coordinate times which are difficult
to define off the surface of the earth. For chronometers outside of
geostationary orbit the nonlinear deviations between the rate of a local
oscillator and an earthbound clock climb
On Mon, 8 Jan 2007, Zefram wrote:
Possibly TT could also be used in some form, for interval calculations
in the pre-caesium age.
In that case you'd need a model (probably involving rubber seconds) of the
TT-UT translation. It doesn't seem worth doing to me because of the
small number of
On Sat, 6 Jan 2007, M. Warner Losh wrote:
Most filesystems store time as UTC anyway...
POSIX time is not UTC :-)
Tony.
--
f.a.n.finch [EMAIL PROTECTED] http://dotat.at/
SOUTHEAST ICELAND: CYCLONIC 6 TO GALE 8, DECREASING 5 OR 6 LATER. ROUGH OR
VERY ROUGH. OCCASIONAL RAIN OR WINTRY SHOWERS.
On Sun, 7 Jan 2007, Rob Seaman wrote:
It's not the correct time under the current standard if the
timekeeping model doesn't implement leap seconds correctly. I don't
think this is an impossible expectation, see http://
www.eecis.udel.edu/~mills/exec.html, starting with the Levine and
Mills
On Sun, 7 Jan 2007, M. Warner Losh wrote:
[POSIX time] is designed to be UTC, but fails to properly implement
UTC's leap seconds and intervals around leapseconds.
From the historical point of view I'd say that UNIX time was originally
designed to be some vague form of UT, and the POSIX
On Sat, 6 Jan 2007, M. Warner Losh wrote:
OSes usually deal with timestamps all the time for various things. To
find out how much CPU to bill a process, to more mondane things.
Having to do all these gymnastics is going to hurt performance.
That's why leap second handling should be done in
On Sat, 6 Jan 2007, Steve Allen wrote:
No two clocks can ever stay in agreement.
I don't think that statement is useful. Most people have a concept of
accuracy within certain tolerances, dependent on the quality of the clock
and its discipline mechanisms. For most purposes a computer's clock
On Sat, 6 Jan 2007, Ashley Yakeley wrote:
Presumably it only needs to know the next leap-second to do this, not
the whole known table?
Kernels sometimes need to deal with historical timestamps (principally
from the filesystem) so it'll need a full table to be able to convert
between POSIX time
On Thu, 4 Jan 2007, Michael Deckers wrote:
This leads me to my question: would it be helpful for POSIX implementors
if each and every UTC timestamp came with the corresponding value of DTAI
attached (instead of DUT1)? Would this even obviate the need for a leap
seconds table?
No,
On Thu, 4 Jan 2007, Zefram wrote:
Interval clock and real-time clock remain conceptually distinct. If you
have a single clock counter alongside a variable epoch, the sum of the
two is the effective real-time clock. I don't think you're gaining
anything by not reifying it.
I'm gaining
On Tue, 2 Jan 2007, Steve Allen wrote:
And, yes, explaining all this is very hard. It's not obvious to the
geek that the political and funding realities are more real than the
underlying physics, but that's the way the world works.
I've been reading The Measurement of Time by Audoin and
On Wed, 3 Jan 2007, Magnus Danielson wrote:
Assuming you have corrected for another gravitational field, yes. The
current SI second indirectly assumes a certain gravitational force, we
is assumed to be at sea level whatever level that is.
Wrong. The SI second is independent of your reference
The time APIs that I am familiar with represent time as an interval based
on a fixed implicit epoch. To reset a clock that is wrong, its couner
value must be set to the correct value. This implies that the system's
real time clock and interval timer must be separate, so that processes
depending on
On Sun, 31 Dec 2006, John Cowan wrote:
However, it's clear that UTC does not contain the sort of jumps
that LCT does, where a single broken-down time may represent
two different UTC seconds.
Not if you include the timezone offset in the representation.
Tony.
--
f.a.n.finch [EMAIL PROTECTED]
On Fri, 29 Dec 2006, Rob Seaman wrote:
Folks keep fretting here about retrieving lists of leap seconds
autonomously, although no specific use case is proffered about why
one needs to use UTC to measure intervals across various and sundry
leap second events.
You need to do so in order to
On Wed, 27 Dec 2006, John Cowan wrote:
If we confine ourselves to the Gregorian calendar, a time interval can
be safely represented as a triple of months, minutes, and seconds.
It seems to me that that would put too much complexity at too low a level
but still without enough complexity to deal
On Thu, 28 Dec 2006, John Cowan wrote:
Distinguo. I am talking about time intervals; you are talking about
periodic events. Two different things.
Still, your minute/month system does not deal with variable-length days.
Tony.
--
f.a.n.finch [EMAIL PROTECTED] http://dotat.at/
SHANNON: SOUTH
On Thu, 28 Dec 2006, M. Warner Losh wrote:
We've accepted a statistical solution for the leap-day problem now for
about 500 years.
The Julian calendar reform was in 46 BC. Astronomers still count Julian
years (365.25 days instead of exact years) when dealing with long MJD
intervals.
Tony.
--
On Mon, 25 Dec 2006, Keith Winstein wrote:
Even if a program is able to calculate TAI-UTC for arbitrary points in the
past and near future, what should a library do when a program asks to
convert between UTC and TAI for some instant further than six months in
the future?
You should treat
On Wed, 27 Dec 2006, Zefram wrote:
So I'm not convinced that leap second uncertainty and timezone
uncertainty should be treated the same way.
I was thinking partly from the point of view of infrastructure: if you
have a mechanism that can keep the system's timezone database up-to-date,
then it
21 matches
Mail list logo
