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
On Wed, 27 Dec 2006, Zefram wrote:
>
> Your principle is probably correct; I'm just saying that the
> implementation you're thinking of doesn't actually satisfy the criterion.
When you quoted me you snipped the bit where I said "its implementation is
far from ideal". This is not just because of th
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 de
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: S
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 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 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 PROTEC
On Tue, 2 Jan 2007, Zefram wrote:
>
> Same for years too: the Roman calendar was naturally arranged so
> that the annual period of growing and harvesting things was entirely
> encompassed by the calendar year. Imagine how annoying it would be if the
> summer overlapped the legal year end. Oh, wai
On Tue, 2 Jan 2007, Warner Losh wrote:
>
> Curiously, BIH is currently, at least in the document I have, expected
> to predict what the value of DUT1 is to .1 second at least a month in
> advance so that frequency standard broadcasts can prepare for changes
> of this value a month in advance. Ther
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 Sun, 31 Dec 2006, Rob Seaman wrote:
>
> But actually, I think we should call leap seconds what they are -
> intercalary events.
Yes! I also liked Zefram's comment "As a calendar, UTC is presently of the
observational variety."
http://www.mail-archive.com/leapsecs@rom.usno.navy.mil/msg01367.htm
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 refer
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 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 s
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?
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 i
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 c
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 ti
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
> M
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 comm
On Sun, 7 Jan 2007, M. Warner Losh wrote:
>
> Having tried it, there are a lot of little 33 second anomolies in many
> applications :-(.
How did you extend the UTC translation back past 1972 if the undelying
clock followed TAI? I assume that beyond some point in the past you say
that the clock tim
On Sun, 7 Jan 2007, Daniel R. Tobias wrote:
>
> Formulas for UTC, as actually defined at the time, go back to 1961
> here:
You helpfully snipped the part where I said that it probably isn't
worth implementing rubber seconds.
> ftp://maia.usno.navy.mil/ser7/tai-utc.dat
> It appears the offset was
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 app
On Sat, 6 Jan 2007, M. Warner Losh wrote:
>
> Unfortunately, the kernel has to have a notion of time stepping around
> a leap-second if it implements ntp.
Surely ntpd could be altered to isolate the kernel from ntp's broken
timescale (assuming the kernel has an atomic seconds count timescale)
Ton
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 cl
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, 15 Jan 2007, Rob Seaman wrote:
>
> I'm wondering whether the clock discipline might better emphasize
> only frequency in such circumstances, as opposed to merely tempering
> the PLL.
I think that if you only correct the frequency of a clock then each time
the frequency makes a deviation (e
On Thu, 18 Jan 2007, M. Warner Losh wrote:
>
> : http://www.ucolick.org/~sla/leapsecs/torino/guinot.pdf
>
> I like figure 8, that shows that 20ms steps lead to 50ms steps lead to
> 100ms steps lead to 1s steps. :-)
In the late 1960s some stations broadcast "stepped atomic time" which had
200ms ste
30 matches
Mail list logo
