Re: An immodest proposal

2006-02-14 Thread Neal McBurnett
First, to review, as I noted on this list just over a month ago, there
is an IETF NTP working group now, working on version 4:

NIST has a leap seconds table:

Current xntpd code can use that table, and transport leap second
tables around using an autokey feature:

There was some discussion of leap seconds at the NTP working group
session of the Internet Engineering Task Force (IETF) meeting in
Vancouver in September:

It is unclear whether the current autokey security mechanism will
end up in an IETF standard, since it is rather different from other
standard internet security mechanisms.

On Tue, Feb 14, 2006 at 02:28:34PM -0700, M. Warner Losh wrote:
 In message: [EMAIL PROTECTED]
 Rob Seaman [EMAIL PROTECTED] writes:
 : On Feb 14, 2006, at 12:50 PM, Markus Kuhn wrote:
 :  You can, of course, define, publish, implement, and promote a new
 :  version (4?) of NTP that can also diseminate TAI, EOPs, leap-second
 :  tables, and other good things. I'm all for it.
 : But why are you for it?  Before investing large amounts of time and
 : money in developing and deploying a large new timekeeping system,
 : wouldn't one want to invest smaller amounts in exploring the issues
 : and options?  Heck - one has to imagine that a number of successful
 : grant applications are lurking around here somewhere.  Time is an
 : issue that cuts across every funding agency out there.

 UTC time stamps in NTP are ambiguous.  TAI ones are not.  UTC time
 stamps do not convey enough information to properly implement things
 like intervals, while TAI ones do.  The NTPNG stuff that I've seen
 appears to consider these problems as worthy of needing a solution and
 they plan on solving them.  It isn't rocket science, but one has to
 divorce ones self from the chauvinistic view that UTC is always best.
 For time exchange, it is not the best, and has many problems around
 the edges.

Yes it is messy, but the tradeoffs are complex.  I don't think the
latest drafts specify NTP timestamps.  I suspect they still rely on
the leap second bit to disambiguate the timestamp on a leap second,
but I haven't checked recently.  They are all linked to from the
charter page I noted above.

 Doing NTP with TAI (and the implied requirement for DTAI) doesn't
 change what time is displayed for users.  It does make it *MUCH*
 easier to get leap seconds right for those users that need them.
 Anything else is madness.  UTC is a display convention, not a sane[*]
 counting convention.

I think that changing to a different over-the-wire timestamp epoch
would just add to the confusion, not make things simpler in practice.
People still need to know UTC, and transmitting the leap second table
info, especially via autokey, is much more complex than the basic
protocol.  But at least this is a standards process conducted in the
open, where you can just get involved directly if you have something
to add.

Neal McBurnett
Signed and/or sealed mail encouraged.  GPG/PGP Keyid: 2C9EBA60


 [*] All variable radix counting conventions are insane by (my humble)
 definition :-).

wikipedia Leap Seconds collaboration

2006-01-23 Thread Neal McBurnett
 Rob Seaman wrote:
 I hope we can all continue this discussion in a more positive manner.

It is the nature of email lists to be good at stimulating discussion,
and bad at generating clear resolutions.  Thus was the FAQ born.  But
we have a more modern technology than FAQs, the wiki, which can more
effectively funnel passionate energy from groups of people with
diverging ideas into coherent descriptions of a variety of viewpoints,
suitable for enlightening the world.  Imperfectly, to be sure, but
better than a mail list

I think the thing we need to do is build on what clarity we can find
in the moment, and document it at wikipedia.  If the folks discussing
the Jesus article can arrive at a relatively stable set of positions
(and last time I looked, they had done remarkably well, considering),
surely we can also.

Note the relatively successful policy of presenting things from a
Neutral Pointof View (NPOV):

So would folks be willing to collaborate at

and related pages?


Neal McBurnett

On Sun, Jan 22, 2006 at 11:47:15PM +, Ed Davies wrote:
 I'm of the opinion that messages on this list (no matter how
 tricky :-) are always positive.  Timekeeping is a fundamental
 issue.  It would be remarkable if there weren't diverse opinions.
 Any negative aspects of this discussion are related to those who
 don't choose to participate.  Which is to say, those who claim to
 have decision making authority over UTC at the ITU, for instance.
 The folks on this list appear to cluster into two groups (speak up if
 your opinion diverges from both):
1) Civil time should remain layered on UTC.  UTC should remain
 largely unchanged.  Leap seconds should continue.
2) Civil time should be layered on some flavor of interval time.
 That timescale might be a variation of TAI called TI.  TI will not
 have leap seconds.

 OK so far.  Actually, I've yet to see any argument which would make
 me deeply unhappy with either of these outcomes.

 The proposal submitted to the ITU is neither of these.  It is:
3) Civil time should remain layered on UTC.  UTC should be modified
 to no longer be a useful approximation to universal time.  Leap
 seconds will be issued 3600 at a time.
 You all know where I stand - but there are worlds of difference
 between #2 and #3 as alternatives to #1.  All three proposals face
 the same looming quadratic emergency.

 Again, OK so far except perhaps a quibble that it seems to be widely
 expected that the leap hour probably would never happen.

 What bothers me about this discussion is that we don't seem to be
 able to get beyond bouncing backwards and forwards between 1  2.

 As soon as anybody puts up any proposal for further detail with
 respect to either of these possible outcomes almost all of the
 response comes back in the form of arguments for the other outcome
 rather than sensible discussion of the idea in itself.

 Maybe for the next little while we should assume one or other
 outcomes each week (1 in odd ISO 8601 numbered weeks, 2 in even
 numbered weeks) and carry on all the discussion in that context.


Re: wikipedia Leap Seconds collaboration

2006-01-23 Thread Neal McBurnett
On Mon, Jan 23, 2006 at 11:20:45AM -0500, Tim Shepard wrote:
 Be careful.  The goals of the folk on this mailing list and the goals
 of the wikipedia project are probably not aligned.

 In particular, note the section Wikipedia is not a publisher of
 original thought.

 It is certainly possible for people on this list to help improve the
 wikipedia's coverage of articles related to time keeping, but the
 wikipedia article is not an appropriate place for a group attempting
 to hash out a consensus on a mailing list to record all of its thoughts.

Thanks - very true.  An important point is that folks should include
references to other sources.  But there are a ton of other sources,
and when we're behaving well, we already reference them in these
discussions.  I think having more folks working on wikipedia will both
help our discussion here, and encourage folks to generate web pages
and other sources for new proposals.

My wikipedia talk page contains a number of relevant policy
references, some of which may be a bit dated:

And note that it is good practice to discuss major or controvertial
proposed changes to, e.g. the leap seconds page, at the associated
discussion page, e.g.


Neal McBurnett
Signed and/or sealed mail encouraged.  GPG/PGP Keyid: 2C9EBA60

Re: Risks of change to UTC

2006-01-20 Thread Neal McBurnett
On Fri, Jan 20, 2006 at 03:12:15PM -0500, John Cowan wrote:
 Rob Seaman scripsit:
  Only a minority (small minority, one would think) of
  systems currently include any DUT1 correction at all - although these
  will perhaps tend to be the most safety-critical applications.  [...]
  That is, of course, one of the major issues for astronomers - we rely
  on UTC providing a 0.9s approximation to UT1 and most of our systems
  don't use DUT1.  Even our high precision applications (in either
  interval or universal time) don't tend to require conversions other
  than as a preprocessing step.  Remediating our systems for such a
  fundamental change to UTC would involve much larger changes than Y2K
  did - algorithms and data structures would have to change, not just
  the width of some string fields and sprinkling some 1900's around.

 I don't understand this.  The first class of applications, those
 that actually receive DUT1 from somewhere, probably have a hard-coded
 assumption that |DUT1| never exceeds 0.9s or at worst 1.0s.  They would
 need remediation.  The second class, which just assumes UTC = UT1
 and doesn't care about subsecond precision, would simply need to be
 front-ended with a routine that got DUT1 from somewhere and mixed it
 with TI to generate their own UT1.  This is technically remediation,
 but of a rather black-box kind.

I don't do this professionally, but here is my guess, and an attempt
at an analogy.  Hopefully the pros will correct me if I'm wrong.

Imagine if someone changed the definition of the meter so that it
changed over time  How would you modify your systems to make sure
that all your units were consistent - that some contractor didn't foul
it up, and give you the wrong measurement, subtly or catastrophically
changing the results?  Like that fabled Mars mission that failed
because some calculations were done with the wrong units?

Today, for many systems, we can assume that DUT1 obeys the
three-decade-old standard and is less than 0.9 s.  If that changes
because the definition of UTC changes, we have effectively a whole new
unit, a non-UT civil time measure.  And made it more confusing by
reusing the old name and invalidating megatons of documentation!

These astronomical and navigation systems currently get inputs of time
from all sorts of other systems and people: other instruments, other
computers, sub-contractors, etc.  Changing the meaning of UTC would
lead to a cascade of systems that changed their own timescales and
I/O formats, meaning that auditing the flow of time data between them
would get more and more complex for a long time.

To sum it up, PLEASE don't fundamentally change the DEFINITION of UTC,
or you risk whole new kinds of confusion.  Hopefully by now the folks
on this list that don't like leap seconds at least have agreed that
any change should be to a new time scale like TI, and announced
decades in advance.

Neal McBurnett
Signed and/or sealed mail encouraged.  GPG/PGP Keyid: 2C9EBA60

Fixing POSIX time

2006-01-19 Thread Neal McBurnett
On Thu, Jan 19, 2006 at 12:59:42PM +0100, Poul-Henning Kamp wrote:
 I would far rather we tried to define a time API for
 POSIX to adopt that makes sense.

 By make sense I mean:

 o conforms to relevant international standards
   ie: recognizes the defininition of leap seconds since
   for all purposes and intents we're probably stuck with
   the blasted things for another 20 years.

 o is workable from a computer architecture point of view
   no more pseudo-decimal timeval/timespec idiocy.

 o Caters to the needs of relevant user communities.

Now you're talking sense, Poul!  Thanks for your proposal.

 Here's a strawman:

 Use a 128 bit signed integer.

 Assign the top 120 bits as one integer field with
 resolution of 1/2^56 seconds.

 Assign the bottom 8 bits to an enum containing the
 timescale in question.

 Assign different timescales very different
 numeric epochs:
 TAI:1972-01-01 00:00:00 UTC

For TAI I'd suggest 1958-01-01, when TAI and UT were set nearly together.
(I've seen more specific references that TAI was set according to both
UT2 and UT1 - but they weren't the same then.  Perhaps within known
error at the time?)

 UTC:MJD's epoch.

That would be midnight in Greenwich of 1858-11-17.  I don't see the
connection, and picking a time for which we don't know UT1 pretty
accurately and authoritatively will cause all kinds of arguments.

I'd pick 1972-01-01, after the rubber-second era, and so that
there is an integer number of seconds difference, as usual.

 UT1:Flamsteads birthday ?
Cute.  1646-08-19

 NTP:defined in RFC1305

== 1900-01-01

 Define functions to convert from one timescale
 to another and define ERANGE as a return value when
 outside the functions ability to do so (ie: future
 dates on UTC).

 Define a compact ascii (no i18n!) representation for machine
 readable use. (Ie: XML, protocols etc).

 Very clearly spell out that any timezone adjustments
 must be carried out-of-band to this field.

 Assign the UTC timescale a identifier of zero.


 Sufficient resolution to represent any likely physical
 measurement or realizable frequency for the forseeable
 future (13.8e-18 seconds resolution).

 Extracting the whole second part can be done by accessing
 only the top 64 bits (which are enough to contain all
 of history and then some).

 Conversion to/from NTP timestamps is trivial.

 Conversion to time_t is a matter of addition and extraction
 of the relevant 32 bits.

 The binary format makes for fast and efficient arithmetic.

 By assigning the UTC timescale an identifier of zero,
 the majority of implementations can disrecard the
 multiple timescale aspect in total.

 Small platform implementations can use a smaller width,
 for instance 64 bits split 48/16 and easily transform
 to standard format by zero extension.

That would work for 9 million years or so.

 High quality implementations will check the bottom 8 bits
 for identity and fail operations that mix but don't match

 Different epochs will make it painfully obvious when people
 mix but don't match timescales in low quality implementations.

Now we just need a name for the proposal

Neal McBurnett

 Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
 FreeBSD committer   | BSD since 4.3-tahoe
 Never attribute to malice what can adequately be explained by incompetence.

Indiana time zone change from Department of Transportation

2006-01-18 Thread Neal McBurnett
This should provide some more grist for understanding the reality of
civil time.  This happens pretty often somewhere in the world.

A DOT final ruling on Indiana came out today, affecting time zones
starting April 2, 2006:

 Under the Uniform Time Act of 1966, the Secretary of Transportation
 has the authority to set time-zone boundaries and must base
 decisions on the convenience of commerce.
 After five months, 22 hours of public hearing testimony and more
 than 6,000 public comments, the U.S. Department of Transportation
 today announced a final rule that will change the clock for eight of
 17 Indiana counties seeking to move to the Central time zone.
 Seventeen Indiana counties asked the Department last September to
 change from Eastern to Central time. On Oct. 25, the Department
 issued a notice proposing Knox, Perry, Pike, St. Joseph and Starke
 counties move from Eastern to Central time, and made no change to
 time zones in the remaining 12 counties.  ...

I heard about this from the time zone mailing list.  See e.g.

Deborah Goldsmith writes to [EMAIL PROTECTED] about

 Based on my reading of this document, only one zone in tzdata is
 affected, America/Indiana/Knox. That zone will start observing US
 Central Time starting April 2, 2006, at the time of the switchover
 to Daylight Savings Time. Probably the easiest thing to do is to
 change the last two lines as follows:

-5:00   -   EST 2006
-5:00   US  E%sT
-5:00   -   EST 2006 Apr 2 2:00
-5:00   US  C%sT

Will your computer's time zone databases be up-to-date then?


Neal McBurnett
Signed and/or sealed mail encouraged.  GPG/PGP Keyid: 2C9EBA60

Re: Monsters from the id

2006-01-17 Thread Neal McBurnett
On Sat, Jan 14, 2006 at 02:09:20AM -0700, Rob Seaman wrote:
On Jan 13, 2006, at 12:46 AM, John Cowan wrote:
  In the end, it will be impossible to maintain the notion that a solar
  day is 24h of 60m of 60s each: we wind up, IIRC, with the solar day
  and lunar month both at about 47 current solar days.

There's a lot of difference between what happens over a billion years
and a million years.  Length of day increases only about 20s per million
years.  Should we be here to care in a million years, only a 1/4 of 1/10
one percent tweak to the length of the civil second would suffice to
our Babylonian clock paradigm to continue in use.

Of course, since there is a future time of equilibrium (though a long
time off...), the quadratic nature of the accumulation of leap
seconds will also stop at some point, and eventually we won't need
them any more.  I hope the 47 day calculation takes the solar tidal
influences into effect, and that the moon has to overcome that.

It makes me wonder when the maximum rate of change in length of day
will come?  Not that we need to plan for events that far in the future
- just some fun astronomy

Neal McBurnett
Signed and/or sealed mail encouraged.  GPG/PGP Keyid: 2C9EBA60

Time standards: RFC3339 and ISO 8601, NTP

2006-01-13 Thread Neal McBurnett
On Fri, Jan 13, 2006 at 11:32:36AM -0700, Warner Losh wrote:
 Has anybody compiled a canonical list of the standards in this area?
 This is the first, I think I've seen ISO 8601 mentioned.

As usual, the IETF does a much better job than the ITU of making this
stuff available to the general public.  See

 RFC 3339 Date and Time on the Internet: Timestamps

  This document defines a date and time format for use in Internet
  protocols that is a profile of the ISO 8601 standard for
  representation of dates and times using the Gregorian calendar.

Written via an open process; free for all to read, copy, distribute,
implement, or be involved in improvements to; with a complete ABNF
syntax specification; compatible with ISO 8601 but without a sufeit of
unnecessary alternative formats like ISO 8601.  Includes a short
section on Leap Seconds, lots of info on time zones, etc.

LEAPSECS members Markus Kuhn and myself contributed suggestions to it.

And as I noted earlier, the IETF ntp working group is working on
updating the NTP standard (RFC1305 on NTP version 3, RFC2030 on SNTP
version 4), again in a relatively refreshing and open manner:

Join us and get a standard TAI spec for NTP!


Neal McBurnett
Signed and/or sealed mail encouraged.  GPG/PGP Keyid: 2C9EBA60

Re: War of the Worlds

2006-01-11 Thread Neal McBurnett
I referenced this page, but missed the most interesting part of it:

 The height of a tidal bulge on a planet is proportional to the
 inverse cube of the distance between the planet and the object
 causing the tidal bulge. The torque which slows down the planet is
 proportional to the inverse sixth power of the distance.

presumably because the the same third power works both on the size of
the bulge and the differential pull on the bulge.  That suggests that
Phobos might raise a lower tide than the sun, but yet have a greater
tidal braking effect.  But I expect the speed of response of the
planet to the tidal force could still play a role in comparing the
Phobos and solar effects.

Data on the speed of change of the orbit of Phobos combined with the
conservation of angular momentum should give a good handle on the size
of the effect from Phobox.
  tidal forces are lowering its orbit, currently at the rate of about
  1.8 metres per century, and in about 50 million years it will
  either impact the surface of Mars or (more likely) break up into a
  planetary ring.

But its too late to do that math tonight


On Wed, Jan 11, 2006 at 11:41:27PM -0700, Neal McBurnett wrote:
 On Wed, Jan 11, 2006 at 11:44:13PM -0500, John Cowan wrote:
  I wouldn't be too quick to dismiss tidal braking from Phobos.  It's
  awfully close to Mars, and tidal braking is as you say an inverse-cube
  effect.  The formula (kai Wikipedia) is (2GMmr)/R^3, where M and m are
  the masses, r is the radius of the primary, and R is the orbital radius
  of the secondary.  The mass of the Earth-Moon system is eight orders of
  magnitude larger than the Mars-Phobos system, and the radius of Earth

 I assume you mean the mass of phobos vs the mass of the moon, not the
 systems, since that is what fits in the raw numbers and equations you
 provide.  But that is less than 7 orders of magnitude different, as I
 read your reference.

  is only twice the radius of Mars, but the ratio of the cubed orbital
  radii is five orders larger for Phobos than for the Moon.  So the tidal
  acceleration of the Moon toward the Earth is only some three orders larger
  than Phobos's toward Mars.  That puts the effect in the same ballpark.

 But the tides from the sun are very significant on earth, and much
 more pronounced on mars.

  (See for
  the relevant masses and radii.)

 A quick google search for   mars  tides  yields much more useful
 and interesting answers.

  the solid-body tides on Mars--caused by the Sun, not by a Martian
  satellite--are large enough to indicate that at least part of that
  planet's core is liquid.
  Early in the study, the investigators realized only a liquid core
  could give rise to a tidal bulge capable of having the observed
  gravitational effect on the spacecraft. And how much bulge is that?
  About a third of an inch.
  Fluid core size of Mars from detection of the solar tide, Science
  300:299-303, April 11,2003)

 But of course we need to treat the web with some skepticism.  I doubt
 this tidbit got it right about what causes the tides (Phobos vs the
  Another way to proceed will be to measure tides produced by Phobos,
  one of Mars' moons. Those tides are 10 times lower than the tides
  produced by the Earth' Moon.

 As for changes in the length of the day, we have to look at the
 mechanism by which tides relate to the slowing of the day:

  There are also tides in the solid earth. The tidal bulge is about 1
  meter high. The moon pulls up this tidal bulge on the earth, there
  is a time delay between the pull of the moon and the time when the
  tidal bulge reaches its maximum height. During this time the
  rotation of the earth carries this tidal bulge around the planet in
  the direction of rotation.

  The moon then pulls on the mass of the tidal bulge and slows the
  rotation of the earth.

 So the degree of slowing is affected by both the size of the bulge,
 how delayed the bulge is, and the angular velocity of the body giving
 rise to the tides, making it harder to compare the effects of the sun
 with rapidly-moving phobos.

 That is what would relate to this aspect of your question:

  How much difference in actual slowing can be attributed to Earth's ocean
  and Mars's lack of one I don't know.

 I also note that the axial orientation of Mars changes widely back and
 forth, which would clearly affect the long term effects due to the sun:

   While Earth's tilt varies from 23 to 25 degrees, the Red Planet's
   actually shifts from 15 to 40 degrees over a 100 million year

 I don't see a handy reference to pull all that together

Re: The real problem with leap seconds

2006-01-07 Thread Neal McBurnett
On Sat, Jan 07, 2006 at 04:02:04PM +0100, Poul-Henning Kamp wrote:
 In message [EMAIL PROTECTED], Ed Davies writes:
 Ignoring the ridiculous parody - no, it's not a weird concept.
 Different timescales are useful for different purposes.  Get
 used to it.

 I have no problems with different timescales for different purposes.

 For instance I very much wish the Astronomers would start to use
 UT1, which is very much their timescale, and stop abusing UTC,
 which isn't, as a convenient approximation.

 But I have big problems with people who want to introduce more
 timescales without thinking through the legal and technical

Yes  And with people that want to redefine existing time scales so
they mean one thing in one era, and another thing in a different era.
As happened with GMT, or the proposed changes to UTC.

 The question is, where in the range of possible timescales is
 it most useful to put civil time.

 Civil time is in the hands of individual governments, and they
 tend to expect their computers to use the same time as the
 rest of their country.

Yes again.  And they are free to choose TAI if they want a uniform
time scale.  But why take the choice of a UTC that remains within 0.9s
of the earth's average rotation rate?

 Nobody here is in any position to do anything about civil time
 or legal time, neither are we in a position to introduce a
 computer time scale in a pathetic attempt to paste over leap

Here we disagree.  I guess you're confirming what is in fact the
current problem as I see it.  We're here because an ITU committee,
shrouded in secrecy, is trying to redefine UTC and the international
distribution of time signals, which most jurisdictions rely on one way
or another as civil time.

But the way the ITU works undermines the sort of open and informed
discussion that is necessary for an issue so sweeping in its legal,
practical and philosophical implications.

The thing that is most flawed here is the process.

 We can talk about _representation_ of a given timescale in computers,
 but there are far too many laws to rewrite if we want to dictate
 which timescale they should use.

But it is inappropriate for ITU to do an end-run around the laws, and
redefine the timescale so that it swings an extra hour back and forth.

Some folks here suggest that legislatures just change their timezones
periodically, forced by the actions of the ITU.  But data was
presented in Torino suggesting a cost to NASA and US DoD of a half a
billion dollars to study, re-engineer and test their systems if UTC
diverges markedly from UT1.  Not an easy thing for a legislature to
deal with.  Again - it's a process problem

The only time there has been an inclulsive international meeting
devoted to the issue, at the colloquium in Torino, There was no
overwhelming consensus on whether the status quo should be maintained
or an alternative should be pursued.

But If a change were to be made one alternative appeared to be
preferred. The essence of this alternative was as follows: 1. Any
change should slowly evolve from the current UTC Standard in
transitioning to a uniform timescale, perhaps to be called Temps
International (TI). 2. A suggested date for inaugurating any change
would be 2022, the 50 TH anniversary of the UTC timescale. The date
suggested is influenced by the lifetimes of existing systems that
would be expensive to change.

So it is distressing to see committee members of the ITU headed in a
different direction.

Neal McBurnett
Signed and/or sealed mail encouraged.  GPG/PGP Keyid: 2C9EBA60

 Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
 FreeBSD committer   | BSD since 4.3-tahoe
 Never attribute to malice what can adequately be explained by incompetence.

predicting leap seconds (was Re: [LEAPSECS] Where the responsibility lies)

2006-01-07 Thread Neal McBurnett
On Wed, Jan 04, 2006 at 07:36:17AM +0100, Poul-Henning Kamp wrote:
 In message [EMAIL PROTECTED], Neal McBurnett writes:
 On Tue, Jan 03, 2006 at 08:32:08PM +0100, Poul-Henning Kamp wrote:
  If we can increase the tolerance to 10sec, IERS can give us the
  leapseconds with 20 years notice and only the minority of computers
  that survive longer than that would need to update the factory
  installed table of leapseconds.
 Do you have any evidence for this assertion?

 It is an educated guess.

 The IERS have already indicated that they belive they could do prediction
 under the 0.9 second tolerance with two or three year horizon.

The Torino Colloquium had some discussion of this.

 Proceedings of the Colloquium on the UTC Timescale held by

 Prediction of Universal Time and LOD Variation
 D. Gambis and C. Bizouard, (IERS)

After a bunch of nice graphs (not all of which were easy to interpret)
I found the periodogram (essentially a discrete Fourier transform of
the input data) interesting.  The way I read it (expert advice
welcomed), the broad peaks at 26 years (0.6 ms/d) and 52 years (0.3
ms/d) suggest that the most common pattern is a gradual cycle a few
decades long of lengthening and shortening of the day, presumably
driven by movements in the earth's mantle and core.

Page 14 of the pdf has a table:

 Skill of the UT1 prediction statistics over 1963-2003

Horizon   Prediction accuracy in ms
3 years   308
2 years   163
1 year 68
180 days   36
90 days21
30 days 7
10 days 3

Perhaps these are worst cases?  It would be nice to have confidence

They presented these conclusions:

 Possibility to predict UT1 with a 1s accuracy at least over 4 years
 using a simple method : seasonal, bias and drift.

 New prediction methods are under investigation (Singular Spectrum
 Analysis, neural network,..)

 Possibility to use Core Angular Momentum prediction for decadal

Steve Allen wrote:

 This deserves discussion and analysis and explanation.

I wrote Dennis McCarthy about that, and he said he'd look up the
details and get back to me next week.  But he did remind me of this,
which I remember seeing in data they published via ftp years ago:

 Regarding the accuracy of these long-term predictions, the IERS
 Rapid Service and Prediction Center located at the U. S. Naval
 Observatory does make predictions of Delta-T in the IERS Annual
 Report.  The algorithm for those predictions was determined
 empirically by testing a wide range of possibilities.  It is
 essentially an auto-regressive model using the past ten years of
 data.  The accuracy based on comparison of observations with what
 would have been predicted using that model is shown in the table
 below.  Note that the accuracy estimates are 1-sigma estimates and
 that excursions of 2-sigma (or more) may not be unexpected.

 |Year in the Future|Accuracy (1s) (seconds|
 |1 | .04  |
 |2 | .08  |
 |3 |  .3  |
 |4 |  .8  |
 |5 |  1.  |
 |6 |  2.  |
 |7 |  2.  |
 |8 |  3.  |
 |9 |  4.  |

The points eventually to

but the links from there to the annual reports seem broken right now.

I still haven't seen any good data on predictions for periods of
longer than 9 years.

Neal McBurnett

Re: ITU Request for Leap Second Experiences

2006-01-06 Thread Neal McBurnett
On Wed, Jan 04, 2006 at 08:24:39PM +, Ed Mirmak wrote:
 Those who have submitted data, plots, or descriptions of system response to
 the leap second addition may want to forward those messages to ITU WP-7A.

 Related to the Nov 2005 U.S. proposal to the ITU to redefine UTC and
 abandon leap seconds, they are soliciting information from various sources
 on both positive and negative experiences.


 They give two different e-mail addresses.  From the first web page:
 Responses can be sent before 13 February 2006 to [EMAIL PROTECTED],
 indicating 'UTC consultation' in the subject of the message.

 From the letter, e-mail address is:

This is so sadly typical of this whole closed ITU process.  The letter
and request, dated December 7, 2005, took over a month to reach the
leapsecs list, the open list of people with a deep interest in and
experience in the subject.  The PDF letter itself is unnecessarily
hard to forward, archive, search, translate or use because it is in
scanned image format, not e.g. text or HTML.

When was this actually published?  E.g. I find no links via google to

And the proposal itself remains unavailable outside the inner circle
as far as I've seen, despite requests from me and others to open it
up.  All I get when I go to their page

and request a document is a request for a TIES account, whatever
that is.

I urge people to share their reports openly with the world by posting
them on the web and sending them to the leapsecs list or other open
forums.  And I urge the ITU to open up their process.

Neal McBurnett

Re: Where the responsibility lies

2006-01-03 Thread Neal McBurnett
On Tue, Jan 03, 2006 at 08:32:08PM +0100, Poul-Henning Kamp wrote:
 If we can increase the tolerance to 10sec, IERS can give us the
 leapseconds with 20 years notice and only the minority of computers
 that survive longer than that would need to update the factory
 installed table of leapseconds.

Do you have any evidence for this assertion?  It seems to me that if
IERS had presented a table in 1980, based on the conventional wisdom
that the earth is continuing to slow down over time, we'd have been
at the edge of that 10-second window in 2000.  And who knows how far
off a 1995 prediction would be in 2015, or what decadal fluctuations
have in store for us in the future.

Anyone have a prediction algorithm in mind, and a result of running it
on the last several decades or centuries of data?

Neal McBurnett

CDMA glitches, and TAI over NTP

2006-01-01 Thread Neal McBurnett
There is an interesting thread at

in which Bruce Penrod notes that some of their customers didn't
configuree their CDMA cell phone basestations right:

 We are pleased to announce that our GPS NTP servers and our CDMA NTP
 servers configured in user leap mode performed the leap properly this
 afternoon.  We are aware that some of the cellular basestations set
 the leap second a day early, and some PCS basestations have still not
 set it.  We regret that some customers apparently had not configured
 their NTP servers to operate in user leap second mode, and apologize
 for any problems this might have caused.

David L. Mills writes:

 There is an obvious remedy here.  If your unit implements Autokey,
 and it does implement just about everything else, it could run in
 TAI and deliver the UTC offsets in an extension field. I would be
 happy to collaborate on an RFC to that effect.

I also note this at

 Recently, the precision time kernel support now incorporated in the
 kernels for Tru64, Solaris, Linux and FreeBSD has been updated to
 improve accuracy and resolution to the nanosecond. In addition, a
 plan has been worked out with NIST for the distribution of
 International Atomic Time (TAI) via NTP using the Autokey protocol.

I'd love to see TAI over NTP, and am glad to see some motion in that
direction.  Anyone know more?


Neal McBurnett

TAI, NTP and IETF; IEEE 1588

2006-01-01 Thread Neal McBurnett
I hadn't run across NIST's leap seconds table before:

I'm finally beginning to catch up on NTP developments over the last
several years, and find that current xntpd code can use that table,
and transport leap second tables around using an autokey feature:

There is an IETF NTP working group now:

There was some discussion of leap seconds at the NTP working group
session of the Internet Engineering Task Force (IETF) meeting in
Vancouver in September:

It is unclear whether the current autokey security mechanism will
end up in an IETF standard, since it is rather different from other
standard internet security mechanisms.

That meeting also mentions IEEE 1588-2002 Standard for a Precision
Clock Synchronization Protocol for Networked Measurement and Control
Systems.  See

It seems that IEEE 1588 time bases are continuous from a defined
epoch, but I don't know much more about that.

There was also a note in the IETF meeting of possible leap second
issues in the RTP protocol.

There was later discussion on the NTP working group mail list
about sending in comments to the ITU.  Here is Steve Allen's
comment, cogent as always, and links to the rest:

I don't know if they ever sent in comments to ITU.

Neal McBurnett
Signed and/or sealed mail encouraged.  GPG/PGP Keyid: 2C9EBA60

leap seconds and Linux/Unix, timezones, and zdump

2005-12-31 Thread Neal McBurnett
Here are some notes on facilities in some Unix systems to show
evidence of leap seconds.  Some recent distributions are out of date
as noted below.  Can folks check others (Solaris, *BSD, etc?).

First, this should work for everyone who cares about time and runs
ntp.  Make sure you're in NTP sync with a host that knows a leap
second is coming.  Look for leap=01 in the output of this:

 $ ntpq -c rv
 assID=0 status=46f4 leap_add_sec, sync_ntp, 15 events, event_peer/strat_chg,
 version=ntpd [EMAIL PROTECTED]:4.2.0a-11-r Mon Mar 14 12:39:28 GMT 2005 (1)?,
 processor=i686, system=Linux/2.6.10-6-386, leap=01, stratum=3,
 precision=-19, rootdelay=158.366, rootdispersion=77.103, peer=17708,
 reftime=c76127cd.19f9acff  Sat, Dec 31 2005  8:52:45.101, poll=7,
 clock=0xc7612b1b.74322291, state=4, offset=-0.430, frequency=37.132,
 error=0.572, jitter=1.795, stability=64.092

Next check to see if your time zone files are up-to-date.  I'm no
expert (help!) but it appears that on many Unix systems, the Olson
notion of right/ timezones allows the system to understand leap

E.g. note the back-to-back output of two date commands, with and
without the right/ timezone prefix:

 $ date; TZ=right/US/Mountain date;
 Sat Dec 31 09:56:22 MST 2005
 Sat Dec 31 09:56:00 MST 2005

That prefix tells the date
command that the system clock includes all seconds (including leap
seconds) since the unix epoch in 1970.  Since that is not true
on my machine, it is off by the 22 leap seconds since then.

But will it know about the 23rd one tomorrow?  That depends on
up-to-date timezone files.

The zdump command shows time discontinuities (daylight savings, leap
seconds, and legal changes) for the files installed somewhere like
/usr/share/zoneinfo.  E.g. here is an excerpt of its output on my
Ubuntu 5.10 (Breezy) system:

 $ zdump -v right/UTC
 right/UTC  Thu Dec 31 23:59:60 1998 UTC = Thu Dec 31 23:59:60 1998 UTC isdst=0 
 right/UTC  Fri Jan  1 00:00:00 1999 UTC = Fri Jan  1 00:00:00 1999 UTC isdst=0 

Note the famous 23:59:60 entry for the last leap second.  But note
that it dosen't now about the 2005 leap second, despite the fact that
my release of Ubuntu came out in October of 2005.  The Debian
releases, including unstable, don't seem to be updated either.  But
Redhat's Fedora core 4 is up-to-date, as are RHEL and centos.

zdump works for other time zones also, including daylight savings
times changes:

 $ zdump -v right/US/Mountain | grep 1998
  right/US/Mountain  Sun Apr  5 08:59:59 1998 UTC = Sun Apr  5 01:59:59 1998 
MST isdst=0 gmtoff=-25200
  right/US/Mountain  Sun Apr  5 09:00:00 1998 UTC = Sun Apr  5 03:00:00 1998 
MDT isdst=1 gmtoff=-21600
  right/US/Mountain  Sun Oct 25 07:59:59 1998 UTC = Sun Oct 25 01:59:59 1998 
MDT isdst=1 gmtoff=-21600
  right/US/Mountain  Sun Oct 25 08:00:00 1998 UTC = Sun Oct 25 01:00:00 1998 
MST isdst=0 gmtoff=-25200
  right/US/Mountain  Thu Dec 31 23:59:60 1998 UTC = Thu Dec 31 16:59:60 1998 
MST isdst=0 gmtoff=-25200
  right/US/Mountain  Fri Jan  1 00:00:00 1999 UTC = Thu Dec 31 17:00:00 1998 
MST isdst=0 gmtoff=-25200

 $ zdump -v right/US/Mountain | grep 2005

  right/US/Mountain  Sun Oct 30 07:59:59 2005 UTC = Sun Oct 30 01:59:59 2005 
MDT isdst=1 gmtoff=-21600
  right/US/Mountain  Sun Oct 30 08:00:00 2005 UTC = Sun Oct 30 01:00:00 2005 
MST isdst=0 gmtoff=-25200

You can get updated time zone tables as indicated at

It also includes changes for US daylight savings in 2007.
The package that needs updating for Debian and Ubuntu is libc6

Neal McBurnett
Signed and/or sealed mail encouraged.  GPG/PGP Keyid: 2C9EBA60

US proposal to abolish leap seconds - Not Found

2005-11-08 Thread Neal McBurnett
Thanks to Steve Allen for his excellent efforts to enable public
discussion of the proposals to abolish leap seconds, difficult though
that task has been, given the official secrecy that has surrounded it.
See e.g. this quote from a Wall Street Journal article in July
 Why the US wants to end link between time and sun

 For now, U.S. officials still regard their proposal as secret,
 despite Dr. Gambis's email and the public comments. The head of
 America's delegation to the ITU's timing committee, D. Wayne Hanson
 of the National Institute of Standards and Technology, declined to
 take calls on the matter. Through a spokeswoman, he said that the
 U.S. proposal is a private matter internal to the ITU and not for
 public discussion.

For a while, the proposal was made public:

On Wed, Sep 28, 2005 at 06:33:22AM -0700, Steve Allen wrote:
 The draft US document which is under consideration for submission is
 available for review and still open for comment

 The significant difference from last year seems to be that leap seconds
 would stop not in 2007 but rather five years after the ITU general
 assembly approves the change.

This URL no longer works, but yields this un-encouraging message:

 Not Found
 The requested object does not exist on this server. The link you
 followed is either outdated, inaccurate, or the server has been
 instructed not to let you have it.

[They could at least offer some entertainment under the circumstances :-)
e.g. Marvin the Paranoid Android moans about requests for missing pages:

If anyone knows of a new place to find the latest proposal, please
post it.  And does anyone know where to find an archive of the
comments made in response to the proposal?

In the meantime, I highly recommend Steve's excellent web page at

which summarizes the cogent arguments of  who disagrees with
the proposal.

Neal McBurnett

leapsecs list still not getting to everyone

2005-11-08 Thread Neal McBurnett
I can post to the leapsecs list, but like some other people, I haven't
gotten any mail from it for over a month.  FYI, here is an update from
the admin at USNO:

- Forwarded message from David Johns [EMAIL PROTECTED] -
 Sorry about the problems with the mailing list.  It's very old
 software and hardware and I can't figure out the current problem.
 Demetrios is currently talking to Tom Van Baak about taking over the
 list.  Hope things improve in the future.

I agree entirely with USNO that LISTPROC is very old software.
I wish I had a sense for how many people are no longer getting
the list.

I hope Demetrios and Tom come up with a good solution soon.  I'd
recommend Mailman, myself.  I think it is important that the list
archives are also ported.  If necessary, I can also help finding a
host for the list.

Neal McBurnett

UTC, leap seconds, and the BIPM, IAU, ITU

2003-01-30 Thread Neal McBurnett
Thanks to Steve for the reference:

I reproduce below a resolution of more specific relevance to this
discussion that was made at that meeting of the International
Astronomical Union.  I'm glad the IAU is looking at a wider range of
options than the International Telecommunication Union
Radiocommunication Study Group is.

The IAU working group is due to report in mid-2003.  Who knows more
about this IAU working group and their discussions?

This brings up the broader question of who is involved in this
decision making process.

ITU CCIR Recommendation 460-4. (188) is available at

EMISSIONS and contains this language:

   UTC is the time-scale maintained by the BIPM, with assistance from
   the International Earth Rotation Service (IERS), which forms the
   basis of a coordinated dissemination of standard frequencies and
   time signals.

That leads me to believe that while the ITU wrote the recommendation
on how to *disseminate* UTC, the actual legal basis for determining UTC
rests with the BIPM, which is part of the General Conference on
Weights and Measures, which also handles the International System of
Units (SI).

Neal McBurnett
GPG/PGP signed and/or sealed mail encouraged.  Keyid: 2C9EBA60

IAU Resolutions Adopted at the 24th General Assembly (Manchester, August 2000)

 Resolution B2 Coordinated Universal Time

 The XXIVth International Astronomical Union General Assembly,


   1. that the definition of Coordinated Universal Time (UTC) relies
   on the astronomical observation of the UT1 time scale in order to
   introduce leap seconds,
   2. that the unpredictability of leap seconds affects modern
   communication and navigation systems,
   3. that astronomical observations provide an accurate estimate of
   the secular deceleration of the Earth?s rate of rotation,


   1. that the IAU establish a working group reporting to Division I
   at the General Assembly in 2003 to consider the redefinition of
   2. that this study discuss whether there is a requirement for leap
   seconds, the possibility of inserting leap seconds at
   pre-determined intervals, and the tolerance limits for UT1-UTC, and
   3. that this study be undertaken in cooperation with the
   appropriate groups of the International Union of Radio Science
   (URSI), the International Telecommunications Union (ITU-R), the
   International Bureau for Weights and Measures (BIPM), the
   International Earth Rotation Service (IERS), and relevant
   navigational agencies.

On Thu, Jan 30, 2003 at 04:25:22PM -0800, Steve Allen wrote:
 The resolutions that have established the change have happened over
 the past four meetings of IAU General Assembly.

 The most recent set of resolutions which switched things from the old,
 non-inertial definitions to the new ones is visible at