Re: Introduction of long term scheduling

2007-01-15 Thread Tony Finch
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. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH. SHOWERS. GOOD.


Re: Introduction of long term scheduling

2007-01-12 Thread Tony Finch
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 into the realm of
 perceptibility. There seems little point in claiming to use a uniform
 time scale for a reference frame whose rate of proper time is notably
 variable from your own.

According to the slides linked from Dave Mills's Timekeeping in the
Interplanetary Internet page, they are planning to sync Mars time to UTC.
http://www.eecis.udel.edu/~mills/ipin.html

Tony.
--
f.a.n.finch  [EMAIL PROTECTED]  http://dotat.at/
LUNDY FASTNET IRISH SEA: SOUTHWEST 6 TO GALE 8. ROUGH OR VERY ROUGH. RAIN OR
DRIZZLE. MODERATE OR GOOD.


Re: Introduction of long term scheduling

2007-01-08 Thread Tony Finch
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 applications that care about that level of precision that
far in the past.

The main requirement for a proleptic timescale is that it is useful for
most practical purposes. Therefore it should not be excessively
complicated, such as requiring a substantially different implementation of
time in the past to time in the present. What we actually did in the past
was make a smooth(ish) transition from universal time to atomic time, so
it would seem reasonable to implement (a simplified version of) that in
our systems. In practice this means saying that we couldn't tell the
difference between universal time and uniform time before a certain date,
which we model as a leap second offset of zero.

Tony.
--
f.a.n.finch  [EMAIL PROTECTED]  http://dotat.at/
BAILEY: SOUTHWEST 5 TO 7 BECOMING VARIABLE 4. ROUGH OR VERY ROUGH. SHOWERS,
RAIN LATER. MODERATE OR GOOD.


Re: Introduction of long term scheduling

2007-01-07 Thread Tony Finch
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. MODERATE OR GOOD.


Re: Introduction of long term scheduling

2007-01-07 Thread Tony Finch
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 PTTI paper.

As http://www.eecis.udel.edu/~mills/leap.html shows, NTP (with kernel
support) is designed to stop the clock over the leap second, which I
don't call correct. Without kernel support it behaves like a pinball
machine (according to Mills).

Tony.
--
f.a.n.finch  [EMAIL PROTECTED]  http://dotat.at/
SOUTHEAST ICELAND: CYCLONIC 6 TO GALE 8, BECOMING VARIABLE 4 FOR A TIME. ROUGH
OR VERY ROUGH. OCCASIONAL RAIN OR WINTRY SHOWERS. MODERATE OR GOOD.


Re: Introduction of long term scheduling

2007-01-07 Thread Tony Finch
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 committee retro-fitted
a weak form of UTC synchronization.

Tony.
--
f.a.n.finch  [EMAIL PROTECTED]  http://dotat.at/
DOGGER FISHER GERMAN BIGHT HUMBER: SOUTHWEST, VEERING NORTHWEST FOR A TIME, 6
TO GALE 8, OCCASIONALLY SEVERE GALE 9 IN DOGGER. ROUGH OR VERY ROUGH. RAIN OR
SHOWERS. MODERATE OR GOOD.


Re: Introduction of long term scheduling

2007-01-06 Thread Tony Finch
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 userland as part of the
conversion from clock (scalar) time to civil (broken-down) time.

Tony.
--
f.a.n.finch  [EMAIL PROTECTED]  http://dotat.at/
SOUTHEAST ICELAND: SOUTHWEST BECOMING CYCLONIC 5 TO 7, PERHAPS GALE 8 LATER.
ROUGH TO HIGH. SQUALLY SHOWERS. MAINLY GOOD.


Re: Introduction of long term scheduling

2007-01-06 Thread Tony Finch
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 can be
kept correct with more than enough accuracy, and certainly enough accuracy
that leap seconds are noticeable.

Tony.
--
f.a.n.finch  [EMAIL PROTECTED]  http://dotat.at/
HEBRIDES BAILEY FAIR ISLE FAEROES: SOUTHWEST 6 TO GALE 8. VERY ROUGH OR HIGH.
RAIN OR SHOWERS. MODERATE OR GOOD.


Re: Introduction of long term scheduling

2007-01-06 Thread Tony Finch
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 and atomic time for compatibility purposes.

Tony.
--
f.a.n.finch  [EMAIL PROTECTED]  http://dotat.at/
SHANNON ROCKALL MALIN: MAINLY WEST OR SOUTHWEST 6 TO GALE 8, OCCASIONALLY
SEVERE GALE 9. VERY ROUGH OR HIGH. RAIN OR SHOWERS. MODERATE OR GOOD.


Re: Introduction of long term scheduling

2007-01-05 Thread Tony Finch
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, because you need to be able to manipulate representations of times
other than the present, so you need a full leap second table. You might as
well distribute it with the time zone database because both are used by
the same component of the system and the leap second table changes more
slowly than the time zone database.

You don't need to transmit TAI-UTC with every timestamp: for example, NTP
and GPS transmit UTC offset tables and updates comparatively infrequently.

Tony.
--
f.a.n.finch  [EMAIL PROTECTED]  http://dotat.at/
WIGHT PORTLAND PLYMOUTH: WEST 4 OR 5, BECOMING CYCLONIC 5 TO 7 FOR A TIME,
THEN NORTHWEST 5 OR 6 LATER. MODERATE OCCASIONALLY ROUGH IN PORTLAND AND
PLYMOUTH. OCCASIONAL RAIN OR DRIZZLE. GOOD OCCASIONALLY MODERATE OR POOR.


Re: how to reset a clock

2007-01-04 Thread Tony Finch
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 simplicity. A count of seconds (perhaps fractional) is much
simpler than a broken-down time. It's much simpler to keep a simple
interval representation separate from leap second and time zone handling.

Your points about recording adjustments across reboots are useful, thanks.

 The solution is to just let the clock run, never adjust it, and treat
 it as an independent seconds count.  You don't care about it showing
 the wrong time, because you don't treat its output as an absolute time.
 Instead, collect your data on how far out it is (or rather, what absolute
 time - output function it is computing) and add the epoch in software.
 Any number of users of the same clock can do this without treading on
 each other's toes.

I think that's what I was suggesting :-)

Tony.
--
f.a.n.finch  [EMAIL PROTECTED]  http://dotat.at/
THAMES DOVER WIGHT PORTLAND PLYMOUTH: WEST 6 TO GALE 8, OCCASIONALLY SEVERE
GALE 9 AT FIRST IN THAMES AND DOVER, DECREASING 4 OR 5 LATER. ROUGH,
OCCASIONALLY MODERATE LATER. SHOWERS DYING OUT. GOOD.


Re: A lurker surfaces

2007-01-03 Thread Tony Finch
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 Guinot, and one
of the things its history of time keeping makes clear is that a lot of the
improvements have been driven by cross-comparison of different measures of
time. At the moment UTC requires the keepers of atomic time and
astronomical time to work together, guaranteeing continued funding and
employment for both :-) If we were to move to a purely atomic foundation
for civil time, I wonder what effect that will have on the organizational
arrangements. Will there continue to be enough cross-checks to drive the
keepers of time to further improvements? Will geodesy be enough to
preserve the astronomers' jobs? I usually take a technical view of things
so this slightly meta way of thinking is unfamiliar to me...

(Audoin and Guinot seem to favour purely atomic time.)

Tony.
--
f.a.n.finch  [EMAIL PROTECTED]  http://dotat.at/
FAIR ISLE FAEROES: SOUTHWESTERLY BECOMING CYCLONIC THEN NORTHWESTERLY 6 TO
GALE 8, OCCASIONALLY SEVERE GALE 9. VERY ROUGH OCCASIONALLY HIGH. RAIN OR
SQUALLY SHOWERS. MODERATE OCCASIONALLY POOR.


Re: A lurker surfaces

2007-01-03 Thread Tony Finch
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.html

Tony.
--
f.a.n.finch  [EMAIL PROTECTED]  http://dotat.at/
BISCAY FITZROY: SOUTHWEST VEERING WEST 6 TO GALE 8, DECREASING 4 OR 5. ROUGH
OR VERY ROUGH. OCCASIONAL RAIN. MODERATE OR GOOD.


Re: Introduction of long term scheduling

2007-01-03 Thread Tony Finch
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 frame, and is
defined according to Einstein's principle of equivalence. What *does*
depend on the gravitational potential at the geoid is TAI (and TT), since
a timescale (unlike a fundamental unit) is relative to a reference frame.

 We still depend on geophysics to some degree.

Note that the standard relativistic transformations between TT, TCG, and
TCB is (since 2000) independent of the geoid. So although the realization
of these timescales is dependent on geophysics (because the atomic clocks
they are ultimately based on are sited on the planet) the mathematical
models try to avoid it.

Tony.
--
f.a.n.finch  [EMAIL PROTECTED]  http://dotat.at/
SOLE LUNDY FASTNET IRISH SEA: SOUTHWEST VEERING WEST OR NORTHWEST 7 TO SEVERE
GALE 9, LATER DECREASING 4 OR 5. ROUGH OR VERY ROUGH, OCCASIONALLY HIGH IN
WEST SOLE. RAIN THEN SCATTERED SHOWERS. MODERATE OR GOOD.


how to reset a clock

2007-01-03 Thread Tony Finch
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 correct relative time continue to work across RTC resets.

Are there any APIs which have an explicit variable epoch, and which reset
the clock by adjusting its epoch instead of its counter? This would
eliminate the need for seperate interval and real-time clocks.

(This post only considers abnormal resets of a grossly incorrect clock,
and ignores corrections based on adjusting the clock's frequency.)

Tony.
--
f.a.n.finch  [EMAIL PROTECTED]  http://dotat.at/
WIGHT PORTLAND PLYMOUTH: SOUTHWEST VEERING WEST OR NORTHWEST 6 TO GALE 8,
OCCASIONALLY SEVERE GALE 9, LATER DECREASING 5 OR 6. ROUGH OR VERY ROUGH.
OCCASIONAL RAIN. MODERATE OR GOOD.


Re: A lurker surfaces

2006-12-31 Thread Tony Finch
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]  http://dotat.at/
THAMES DOVER WIGHT PORTLAND PLYMOUTH BISCAY: SOUTHWEST VEERING WEST 6 TO GALE
8, INCREASING 7 TO SEVERE GALE 9, PERHAPS STORM 10 LATER. ROUGH OR VERY ROUGH
BUT HIGH IN PLYMOUTH AND BISCAY. RAIN OR SQUALLY SHOWERS. MODERATE OR GOOD.


Re: Mechanism to provide tai-utc.dat locally

2006-12-29 Thread Tony Finch
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 implement an accurate clock, since the clock
produces interval time and you need a way to convert its output to time of
day.

 M. Warner Losh wrote:
 
  Daylight savings time and time zones prove that society at large has a
  very high tolerance for variations between the mean solar time at an
  arbitrary location, maybe hundreds of miles away, and the local time.

 This is a static offset.

No, it is subject to arbitrary political variations.

Tony.
--
f.a.n.finch  [EMAIL PROTECTED]  http://dotat.at/
SHANNON: SOUTHERLY BECOMING CYCLONIC GALE 8 TO STORM 10, OCCASIONALLY VIOLENT
STORM 11. HIGH. RAIN OR SQUALLY SHOWERS. MODERATE, OCCASIONALLY POOR.


Re: Mechanism to provide tai-utc.dat locally

2006-12-28 Thread Tony Finch
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 with the whole problem. How
does your proposal deal with local time zone changes, e.g. same time
tomorrow, or times based on weeks, e.g. last thursday in the month? I
don't see much point in having an intermediate stage between day counts
and fully broken down dates. Similarly for times, I favour a split between
interval time (which the RTC would produce) and broken-down time of day
plus day count (with leap seconds and local time handled in the latter
layer).

Tony.
--
f.a.n.finch  [EMAIL PROTECTED]  http://dotat.at/
FISHER GERMAN BIGHT HUMBER: NORTHWEST BACKING SOUTH 4 OR 5, INCREASING 6 OR 7.
SLIGHT OR MODERATE, OCCASIONALLY ROUGH LATER. OCCASIONAL RAIN. MODERATE OR
GOOD.


Re: Mechanism to provide tai-utc.dat locally

2006-12-28 Thread Tony Finch
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 BECOMING CYCLONIC 7 TO SEVERE GALE 9, OCCASIONALLY STORM 10,
PERHAPS VIOLENT STORM 11 LATER. VERY ROUGH OCCASIONALLY HIGH. RAIN OR SHOWERS.
MODERATE OR GOOD.


Re: Mechanism to provide tai-utc.dat locally

2006-12-28 Thread Tony Finch
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.
--
f.a.n.finch  [EMAIL PROTECTED]  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: SOUTHERLY 7 OR GALE 8, OCCASIONALLY SEVERE
GALE 9. ROUGH OR VERY ROUGH. RAIN THEN SQUALLY SHOWERS. MODERATE, OCCASIONALLY
POOR.


Re: Mechanism to provide tai-utc.dat locally

2006-12-27 Thread Tony Finch
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 the update problem: the whole
library is built around time_t and the traditional time API both of which
are hopeless.

Tony.
--
f.a.n.finch  [EMAIL PROTECTED]  http://dotat.at/
NORTH UTSIRE SOUTH UTSIRE: WEST OR NORTHWEST 3 OR 4, OCCASIONALLY 5. SLIGHT.
FAIR. MODERATE OR GOOD.


Re: Mechanism to provide tai-utc.dat locally

2006-12-26 Thread Tony Finch
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 this kind of conversion in the same way that you treat
local time zone conversions, which are also unpredictable.

Tony.
--
f.a.n.finch  [EMAIL PROTECTED]  http://dotat.at/
SOLE: SOUTHEASTERLY 5 TO 7, OCCASIONALLY GALE 8, VEERING SOUTHWESTERLY 3 OR 4.
MODERATE OR ROUGH. RAIN. MODERATE OR GOOD.


Re: Mechanism to provide tai-utc.dat locally

2006-12-26 Thread Tony Finch
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 is adequate for keeping the leap second table up-to-date. This is
an approach to answering Ashley's initial question, and the one taken by
Linux's use of the Olson database (though its implementation is far from
ideal).

 The nature of the uncertainty is very different.  The uncertainty of
 future UTC can be managed, but for timezones the only sane path is to
 eschew their use entirely.

That isn't possible for applications like appointment books and job
schedulers. As Warner suggests, you need to calculate future times
provisionally, and in a way that insulates you from discontinuities.
For example, same time tomorrow instead of in 86400 seconds.

Tony.
--
f.a.n.finch  [EMAIL PROTECTED]  http://dotat.at/
FAIR ISLE FAEROES SOUTHEAST ICELAND: SOUTH OR SOUTHWEST 4 OR 5, DECREASING 3
IN FAIR ISLE. MODERATE. FAIR. MODERATE OR GOOD.