Re: What problems do leap seconds *really* create?

2003-01-30 Thread Steve Allen
On Thu 2003-01-30T00:28:57 -0800, Ken Pizzini hath writ:
 Right, but in its way UT1 is king because that is the measure of
 earth-position time which is used in the definition of our current
 time standard, UTC.

I would go so far as to argue that UT1 is not time, but angle.
UT1 does not measure what we now understand to be time, it measures
the spin of a nonrigid body whose atmosphere, oceans, mantle, core,
sun, and moon are all doing strange things impede uniformity.
Unfortunately we have a history which very strongly confuses the
distinction, not the least being because we still communicate UT1 with
units that make it look like time.  For technical communications it
might be a trend towards better thinking if the switch were made to
use a vocabulary which always gives UT1 in degrees.

Some appear
 to feel that this history is important to preserve in our civil time
 standard (UT1 rules!  UTC ain't broke); others appear to feel
 that it is irrelevant (Just use TAI, dammit!).

Do not confuse things.  I do not think that there is anyone on this
list, or anywhere, who would disagree with the current use and
definitions of UT1 and TAI.  Only civil time and UTC are at issue.

--
Steve Allen  UCO/Lick Observatory   Santa Cruz, CA 95064
[EMAIL PROTECTED]  Voice: +1 831 459 3046 http://www.ucolick.org/~sla
PGP: 1024/E46978C5   F6 78 D1 10 62 94 8F 2E49 89 0E FE 26 B4 14 93



Re: What problems do leap seconds *really* create?

2003-01-30 Thread Markus Kuhn
John Cowan wrote on 2003-01-30 13:01 UTC:
 Markus Kuhn scripsit:

  Unix timestamps have always been meant to be an encoding of a
  best-effort approximation of UTC.

 Unix is in fact older than UTC.

This is getting slightly off-topic, but Unix slowly evolved and was
reimplemented various times during the first half of the 1970s and the
early versions probably didn't have a clock. It didn't exist in practice
outside Bell Labs before 1976. Gory details are on:

  http://www.bell-labs.com/history/unix/firstport.html

  They have always counted the non-leap seconds since 1970-01-01.

 The Posix interpretation is only a few years old, and a break with Unix
 history.  Before that, time_t ticked SI seconds since the epoch (i.e.
 1970-01-01:00:00:00 GMT = 1970-01-01:00:00:10 TAI).

Sorry, you just make this up. Unix machines ticked the seconds of their
local oscillator from boot to shutdown. Local oscillator seconds differ
from SI seconds by typically +/- 10^-5 s or worse. Unix time had
multiple or fractional inserted and deleted leap seconds whenever the
administrator brutally readjusted the local clock using the
settimeofday(2) system call closer to UTC. Only much later in the 1980s
did the Berkeley Unix version add the adjtime(2) system call to allow
smooth manual adjustment towards UTC by changing the length of the Unix
second relative to the local oscillator second by IIRC up to 1%. The
entire question of the relation of Unix time to UTC and TAI came only up
at roughly the same time as POSIX in the late 1980s when people started
to get interested in time synchronization over LANs and (in Europe)
DCF77 radio receivers.

 The time(2) man
 page in the Sixth Edition (unchanged in the Seventh) of Research
 Unix says:

 .I Time
 returns the time since 00:00:00 GMT, Jan. 1, 1970, measured
 in seconds.

Today we distinguish between civilian (UTC non-leap) seconds and
physical (SI) seconds. The authors of that manual very obviously didn't
make that distinction and you should not misrepresent them by claiming
that they did.

 IOW, it is a count of elapsed time since a certain moment, measured in
 SI seconds, and not an encoding of anything.

In practice, the source code shows that time_t values are converted to
UTC clock displays without a leap second table, therefore they clearly
are just meant to be an encoding of UTC clock display values and nothing
else. Implementations that do anything else are purely experimental, not
widely used, and can cause serious disruption in practice.

 Even today, you can install the ADO (and probably GNU) packages in
 either of two ways:  posix, in which there are no leap seconds and
 time_t's get the POSIX interpretation you reference; and right, in
 which there are leap seconds and time_t is a count of seconds.
 Try setting your TZ to right/whatever and see what you get.

The so-called right mode in Olson's timezone library on that makes
time_t an encoding of TAI+10s instead of UTC, as well as Dan Bernstein's
libtai are both commonly regarded to be experimental implementations and
not recommended for general use. I don't know anyone who uses TAI+10s on
Unix in practice and it violates various standards. The reasons for why
it shouldn't be used have been discussed in great detail on Olson's tz
mailing list. You have completely misunderstood Unix time if you think
that the Olson right configuration has anything to do with it.

Markus

--
Markus Kuhn, Computer Lab, Univ of Cambridge, GB
http://www.cl.cam.ac.uk/~mgk25/ | __oo_O..O_oo__



Re: What problems do leap seconds *really* create?

2003-01-30 Thread Clive D.W. Feather
John Cowan said:
 Fact 2 is that the old 1980s pre-POSIX Unix manuals talked about GMT and
 not UTC. This strongly suggests that the authors were unfamiliar with
 both TAI and UTC. The seconds they refer to behave more like UT1
 seconds than like TAI/SI seconds, i.e. they are Earth rotation angles
 and not Caesium oscillations.
 Where do you see any reference in the old documentation to the rotation of
 the Earth?  The authors of those man pages were engineers, and they knew
 perfectly well what a second was and is (since 1967), and they certainly
 knew the difference between measuring/counting and encoding.

I was around, though on the margins, when the first POSIX standard was
being written. If there had been an awareness of the difference between UTC
and GMT, I am the sort of person who would have leaped on it in an attempt
to win a Weirdnix prize. I offer this as weak evidence in support of
Marcus - nobody was discussing stuff at this level of detail.

--
Clive D.W. Feather  | Work:  [EMAIL PROTECTED]   | Tel:  +44 20 8371 1138
Internet Expert | Home:  [EMAIL PROTECTED]  | Fax:  +44 870 051 9937
Demon Internet  | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc||



Re: What problems do leap seconds *really* create?

2003-01-29 Thread Markus Kuhn
John Cowan wrote on 2003-01-29 17:56 UTC:
 The problem is that they are not announced much in advance, and one needs
 to keep a list of them back to 1972 which grows quadratically in size.

Is this a real problem?

Who really needs to maintain a full list of leap seconds and for what
application exactly?

Who needs to know about a leap second more than half a year in advance
but has no access to a time signal broadcasting service (the better ones
of which all carry leap second announcement information today)?

For pretty much any leapsecond-aware time-critical application that I
can think of, it seems more than sufficient to know:

  - the nearest leap second to now
  - TAI-UTC now
  - UT1-UTC now

This information is trivial to broadcast in a fixed-width data format.
(For the nitpicker: The number of bits to represent TAI-UTC admittendly
grows logarithmically as be move away from 1950. We know we can live
with that, as O(log(t)) is equivalent to O(1) for engineering purposes.)

Markus

--
Markus Kuhn, Computer Lab, Univ of Cambridge, GB
http://www.cl.cam.ac.uk/~mgk25/ | __oo_O..O_oo__



Re: What problems do leap seconds *really* create?

2003-01-29 Thread John Cowan
William Thompson scripsit:

 Any application which seeks to calculate the difference in time between
 two events recorded in UTC time needs to know if there are any leap
 seconds between the start and stop time.  For example, suppose you
 were studying solar flares, and analyzing some data taken in 1998,
 and you saw a burst of hard X-rays at 23:59:53 UT on Dec 31, followed
 by a rise in EUV emission at 00:00:10 UT the next day.  You'd think
 that the delay time between the two would be 17 seconds, but it's
 really 18 seconds because of the leap second introduced that day.

Thanks for the example.  Of course it is not astronomy-specific: the same
thing applies if you are calculating how long somebody spoke for in
field linguistics, or the amount of time it takes a moving part to stop
moving in engineering.  What we are dealing with here is time-zone independent
civil time.

 That's a vital difference for the scientific analysis of the data.

Indeed.

 And yes, part of that software package includes a list of all
 leapseconds added since 1 Jan 1972.  Currently, my software doesn't
 handle TAI/UTC conversions between 1958 and 1972, when UTC seconds
 had varying lengths.

Modern Unix time packages (both GNU and ADO) assume that TAI-UTC was 10
from the epoch until 1972-06-30T23:59:60 UTC.  Or to put it another way,
the epoch was at 1970-01-01T00:00:10 TAI.

When did the TAI timescale first come into existence?  One answer
seems to be that TAI was born on 1958-01-01T00:00:00 UT2, which was
also 1958-01-01T00:00:00 TAI.  But OTOH the definition of the SI second
changed in 1967 and again in 1997.  What did these changes do to the
uniformity of TAI?

I found the following interesting statement at
http://www.maa.mhn.de/Scholar/times.html :

#  The need for leap seconds is not caused by the secular slowdown
# of Earth's rotation (which is less than 2 milliseconds per century)
# but by irregular variations in this rotation and by the fact that the
# definition of the SI-second is fixed on the duration of the year 1900
# which was shorter than average.

--
Not to perambulate  || John Cowan [EMAIL PROTECTED]
the corridors   || http://www.reutershealth.com
during the hours of repose  || http://www.ccil.org/~cowan
in the boots of ascension.  \\ Sign in Austrian ski-resort hotel



Re: What problems do leap seconds *really* create?

2003-01-29 Thread Rob Seaman
Those of us with a day job may be having a hard time keeping up with
the messages as they arrive fast and furious :-)

 #  The need for leap seconds is not caused by the secular slowdown
 # of Earth's rotation (which is less than 2 milliseconds per century)
 # but by irregular variations in this rotation and by the fact that the
 # definition of the SI-second is fixed on the duration of the year 1900
 # which was shorter than average.

Basically we don't have leap seconds because the Earth's rotation is
slowing down (by transfering angular momentum to the Moon).  Rather,
we have leap seconds because the Earth has *already* slowed down since
1900.  See the rather consistent slope of about 7 seconds per decade
on the plot of UT1-UTC (with leap seconds removed) versus date:
ftp://gemini.tuc.noao.edu/pub/seaman/leap/noleap.pdf

The current dynamical effects are the subtle wiggles imposed on this
trend.  This is actually a fairly useful bias since it guarantees (short
of asteroid impact or armageddon) that there will be no negative leap
seconds.

Again, please note how consistent the divergence is between atomic
and Earth timescales over decade long periods.  Where precisely is the
urgency to adopt a quick fix?

Ken Pizzini says:

 I realize that the astronomical community has evolved to a consensus
 that UT1 (approximated by UTC) is a highly useful way to mark time,

Rather we've evolved a consensus that different problems require
different systems of time - not surprising, since we invented most
of them.

 with the additional feature that it is usable as a civil time standard,

It isn't just usable - it is preferable to many alternatives.

 but there is so much of that evolution which is based on historical
 accident rather than purely technical requirements

Historical accident makes it sound like the practice of timekeeping
was some afterthought to events.  The reality is that timekeeping has
often been central to other, bloodier, battles - from Augustus Caesar
appropriating an extra day from February into his month - to Harrison's
chronometer that was instrumental to the building of a later empire.

Is there nobody on this list who was present at the birth of UTC?
It is a good, solid, pragmatic standard.  The ability to issue leap
seconds monthly clearly represents a recognition that these would be
needed to preserve the standard over hundreds or thousands of years.

 that I find it hard to believe that there would be no possible way to
 improve upon it, even after non-astronomical constraints are factored
 in, if only it were possible to start anew with a clean slate.

The astronomical community isn't afraid to discuss a successor to UTC.
The mere presence here of several vocal members of that community should
demonstrate this.  There is always room for improvement - although the
elegant simplicity of UTC will be hard to rival.

What we object to (if my friends don't mind my saying so) is not the
idea of *improving* UTC. What we object to is this current process
which appears to be an attempt to discard the standard entirely -
and to do so with minimal consent.

Please!  Let's talk about ways to improve UTC and civil timekeeping.
And let's take the appropriate amount of time to reach a decision -
say - 40 or 50 years.  In the mean time, let's pay attention to the
real question, which is how to build an infrastructure that will
dramatically improve the dissemination of all time signals.

NTP is a lovely mechanism.  Astronomers are likely among its most
passionate users.  The limitations of NTP or of any other general
purpose mechanism for disseminating time signals should not limit the
definition of the standards behind those signals.  Rather, NTP, WWV,
GPS - and heavens to Betsy, GLONASS - should be built in a fashion that
can handle a general parametrized time standard.  This should include a
static offset as used by GPS, as well as frequently or infrequently
introduced time jumps of variable sizes in either direction as required
by daylight saving or leap seconds.  These systems should perhaps be
parametrized to support epsilon schemes as described by Calabretta or
by Kuhn's UTS.  And a general purpose time distribution mechanism
should support differing rates as required by sidereal time, for
example.

Similarly, personnel associated with various projects are expected to
know enough engineering to build incredibly complicated radio equipment
and other devices.  Why aren't these same projects expected to handle
time issues with similar professionalism?  If they need unsegmented
time - they should use some variation of TAI - and if they don't require
an Earth fixed time scale - they shouldn't use UTC.  And if they do use
UTC, well then, they should figure out how to handle leap seconds.

Leap seconds are discussed very prominently in a very short document.

Rob Seaman
National Optical Astronomy Observatory



Re: What problems do leap seconds *really* create?

2003-01-29 Thread Steve Allen
On Wed 2003-01-29T15:43:24 -0700, Rob Seaman hath writ:
 Please!  Let's talk about ways to improve UTC and civil timekeeping.
 And let's take the appropriate amount of time to reach a decision -
 say - 40 or 50 years.  In the mean time, let's pay attention to the
 real question, which is how to build an infrastructure that will
 dramatically improve the dissemination of all time signals.

Alas, we do not have 40 years, we have less than 35.  The end of
32-bit Unix time is 2038-01-19T03:14:07.  Well before that the Unixes
of the future must have decided on the proper way to implement the
algorithms for handling 64-bit time_t when receiving inputs from the
NTP(s) of the future.

Although there are many technical aspects to the situation, for
practical purposes any change of UTC is legislation.  Effective
legislation seeks the common good while remaining congruent with the
will of the people.  When that will is split because of pre-existing
practices and notions of what is good, the process inevitably becomes
political.  If this change is going to affect civil time, then,
politically speaking, the 32-bit end of time is a looming deadline
that should serve to motivate an answer about the fate of UTC within
the next 10 years.

In the mean time we may learn that a fifth fundamental force has
implications for the spacetime metric that invalidate all the current
time scales in use by astrophysics.  As before, the response to that
kind of paradigm shift in physical thinking would trigger the creation
of yet more time scales to be used by astronomers.  The old time
scales would remain, unmodified, and less used.

On Mon 2003-01-27T17:32:19 -0500, John Cowan hath writ:
 I would have no problem with deciding now to change UTC, effective in 2033.

Over that interval all the observatories in the world could assuredly
handle any change.  But in the context of the history of time scales,
changing the character of UTC would still be the wrong thing to do.

--
Steve Allen  UCO/Lick Observatory   Santa Cruz, CA 95064
[EMAIL PROTECTED]  Voice: +1 831 459 3046 http://www.ucolick.org/~sla
PGP: 1024/E46978C5   F6 78 D1 10 62 94 8F 2E49 89 0E FE 26 B4 14 93



Re: What problems do leap seconds *really* create?

2003-01-29 Thread Mark Calabretta
On Wed 2003/01/29 15:43:24 PDT, Rob Seaman wrote
in a message to: [EMAIL PROTECTED]

Basically we don't have leap seconds because the Earth's rotation is
slowing down (by transfering angular momentum to the Moon).  Rather,
we have leap seconds because the Earth has *already* slowed down since
1900.  See the rather consistent slope of about 7 seconds per decade
on the plot of UT1-UTC (with leap seconds removed) versus date:
ftp://gemini.tuc.noao.edu/pub/seaman/leap/noleap.pdf

The current dynamical effects are the subtle wiggles imposed on this
trend.  This is actually a fairly useful bias since it guarantees (short
of asteroid impact or armageddon) that there will be no negative leap
seconds.

Again, please note how consistent the divergence is between atomic
and Earth timescales over decade long periods.  Where precisely is the
urgency to adopt a quick fix?

I agree with you that there is plenty of time to make an informed
decision, that nothing need be done on a timescale of decades, and
also that the process to date appears, at least to some of us, to have
bordered on Machiavellian, though I'm sure it was not.

It's also true that the leap-seconds we have now do come from the
slowdown since 1900.  However, your consistent slope of about
7 seconds per decade obscures the basic point about the long term
future of UTC.  Your graph shows a linear approximation to what is
actually a parabola.

The graph in the GPS World article shows the long term trend much
better.  Though its fit to a parabola is not much more convincing - we
do know that it is a parabola because the physics of the Earth-Moon
dynamical system tells us so.  The wiggles are caused by the motion of
dense material in the Earth's mantle which cause the Earth's moment of
inertia to vary unpredictably, thus causing it to spin up as well as
down.  They are what leap-seconds were originally designed to handle,
not the predictable, long-term secular deceleration of the Earth's
rotation.

Thus, what is 7 seconds per decade now will become 35 seconds per
decade in another two hundred years time.  When you add up all those
so-many-seconds per decade over the next 20 decades the cumulative
error runs to many minutes - already nearly 60s by 2050 according to
the GPS World article, not 35s by a linear extrapolation, and more
than 140s by 2100, double the linear-extrapolated value.

The cumulative error grows quadratically; that is the problem.

Mark Calabretta
ATNF