Re: Introduction of long term scheduling

2007-01-07 Thread David Malone
 So you think it is appropriate to demand that ever computer with a
 clock should suffer biannual software upgrades if it is not connected
 to a network where it can get NTP or similar service ?

 I know people who will disagree with you:

 Air traffic control
 Train control

 and the list goes on.

FWIW, I believe most hospitals are more than capable of looking
after equipment with complex maintenance schedules. They have
endoscopes, blood gas analysers, gamma cameras, MRI machines,
dialysis machines and a rake of other stuff that has a schedule
requiring attention more regurally than once every 6 months.

I am not sure how much un-networked equipment that requires UTC to
1 second and doesn't already have a suitable maintenance schedule
exists in hospitals.


Re: building consensus

2006-06-08 Thread David Malone
  I belive this was because the year followed the taxation cycle of the
  government whereas the day+month followed the religiously inherited

 Indeed.  For that matter, the start of the U.K. tax year was left alone
 when the calendar changed, and is now 6 April (it should be 7 April,
 but for whatever reason no adjustment for 1900 was made).

Unsurprisingly, Ireland originally followed the UK tax year. However,
in 2000 the tax year ran from April 6 until December 31. Since then
our tax year is in sync with the calendar year.

(I guess this is a recent example of calendar reform that went
relatively smoothly.)


Re: building consensus

2006-06-08 Thread David Malone
 Quintilis was renamed after Julius Caesar.  Later Sextilis was renamed
 after Augustus Caesar.  It is often said that the month lengths were
 changed at the same time, but at least one version of that story is
 fabricated and there's a distinct lack of evidence for it.  Other emperors
 had months renamed after themselves too, but those names didn't stick.
 There's no evidence that any of them was accompanied by changes in the
 lengths of months either.

The Oxford Companion to the Year is pretty explicit about this in its
chapter on the Roman Calendar. It says that before Julius Caesar:

Ianuarius29   Quinctilis   31
Februarius   28   Sextis   29
Martius  31   September29
Aprilis  29   October  31
Maius31   November 29
Iunius   29   December 29

The reason was most of the months had odd lengths because odd numbers
were lucky, but to get the year to have an odd number of days you
need one month to have an even number of days.  There was a leap
month system where Februarius was cut short and an extra month was

After the reform:

Ianuarius31   Quinctilis   31
Februarius   28   Sextis   31
Martius  31   September30
Aprilis  30   October  31
Maius31   November 30
Iunius   30   December 31

They also explain where the extra days were inserted. They say
Quinctilis was renamed Julius after he'd been murdered. Their
entry for 30 February notes:

There is no truth in the assertion by some modern (but no
ancient) writers that Julius Caesar gave all the odd months
31 days, February 29 days and 30 in a leap year, and all
the even months (including Oct) 30, but that Augustus upsets
the logical arangement in order to make his month of August
as long as Caesar's July. Nevertheless, 30 February has
existed three times in the calendars of particular countries:
once in Sweden, twice in the Soviet Union.


Re: Risks of change to UTC

2006-01-23 Thread David Malone
 Professional and amateur astronomers are not the only ones who need good
 estimates of UT1.

I've been wondering about this for a bit. Do astronomers and
navigators actually want UT1 or do they want GMST? Since UT1 is
based on a mean sun, which I guess no one actually observs, it would
seem that GMST would be much more useful for figuring out your
position or observing something.

As far as I can see from my 1992 edition of the Explanatory Supplement
to the Astronomical Almanac, UT1 and GMST were (defined?) to be
related to one another by a cubic (2.24-1):

GMST1 of 0hUT1 =
24110.54841s + 8640184.812877s T + 0.093104s T^2 + 0.062s T^3

What I don't know is: are the coefficients of this equation constant,
or periodically updated by the IAU? Do astronomers, navigators and
almanacs have to update their calculations when/if the IAU make a

Why do I think they may change? Well, In older explanatory supplements
to the IERS bulletins, such as this one:

they give a reference for the relationship used as a paper by Aoki
et al., 1982. However, in this more recent explanatory supplement:

the relationship seems to have been changed to ones documented in
(Capitaine et al., 2000, Capitaine et al., 2003, McCarthy and Petit,
2004). They say that that This relationship was developed to
maintain consistency with the previous defining relationship, but
I think this probably means that they were stitched together in a
smooth way, not that they are identical.

If it is the case that the GMST/UT1 relationship is changed regularly
and astronomers/navigators have to keep up with those changes, then
leap seconds could be put into this relationship (amounting to
moving the mean sun when needed).

I'm guessing that this suggestion is only slightly less crazy than
strapping rockets onto the Earth to speed up its rotation ;-)


Re: The real problem with leap seconds

2006-01-12 Thread David Malone
Yes: there is an order on the set of values of timescales -
it is a basic property of spacetime models that one can distinguish
past and present, at least locally. Spacetime is a differentiable
4-dimensional manifold, its coordinate functions are usually two
times differentiable or more. In particular, the set of values of
timescales does indeed have a topology (which is Hausdorff).

Sure - this is a reasonable definition of timescale, but I don't
think it is wide enough to include UTC. As I understand it, and
everyone will correct me if I'm wrong, UTC is not intended to be
directly related to spacetime coordinates at all. UTC is (currently)
an aproximation to the direction the earth is facing and is adjusted
according to how long it takes the earth to end up facing the same
direction again.

All of this is completely independent from the choice of a particular
calendar or of the time units to be used for expressing timescale values.

I'd agree with this for TAI (including that it should be the integral
of a nice 1-form), but I'm not so sure for UTC.

If you subtract a time from a timescale value, you get another
timescale value. If you mean to say that UTC takes its values in a
different space than TAI then you cannot agree with UTC = TAI - DTAI,
as in the official definition of UTC. And if you say that
UTC - TAI can be discontinuous (as a function of whatever)
with both UTC and TAI continuous then you must have a subtraction that
is not continuous. Strange indeed. Where did I misinterpret your post?

Yep - you've picked up my intent correctly. I'm saying that subtraction
is a stange operator taking a UTC value and a TAI value and gives
you something that's a real number.

The reason that I came to this conclusion is because none of the
documents I've read say that UTC can be expressed as a real number
- they all suggest it is expressed as labelled seconds. (For example,
see the way that Rec. 460-4 gives UTC values - I've never seen an
official looking document that tries to write UTC as a real.)


Re: The real problem with leap seconds

2006-01-11 Thread David Malone
[A lot of discussion on this list seem to revolve around people
understanding terms in different ways. In an impractical example
of that spirit...]

I do not understand. As a function of TAI, UTC is neither continuous
nor monotone increasing in the mathematical sense.

To say if TAI is a monotone function of UTC, you need to put an
order on the set of possible TAI and UTC values. To say if UTC is
a continious function of TAI, you need to put a topology on both.

To me, TAI seems to be a union of copies of [0,1) labelled by
YEAR-MM-DD HH:MM:SS where you glue the ends together in the obvious
way and SS runs from 00-59. You then put the obvious order on it
that makes it look like the real numbers.

OTOH, UTC seems to be a union of copies of [0,1) labelled by
YEAR-MM-DD HH:MM:SS where SS runs from 00-60. You glue both the end
of second 59 and 60 to the start of the next minute, in adition to
the obvious glueing.

I haven't checked all the details, but seems to me that you can put
a reasonable topology and order on the set of UTC values that
will make UTC a continious monotone function of TAI. The topology
is unlikely to be Hausdorf, but you can't have everything.

  DTAI jumped
  from 32 s to 33 s; thus, UTC is not a monotone increasing function of
  TAI either.

Since DTAI involves subtracting quantities that aren't real numbers,
you can't conclude that a discontinuity in DTAI results in a
discontinuity in UTC.


Re: NTP behavior in Australia

2006-01-02 Thread David Malone
 I grabbed a set if IP#'s from and monitored them in the 24
 hours before and 8 hours after the leap.

I did something similar using the public NTP server lists on the
ntp wiki. I'm still collecting the data, but I have some plots of
what's happening with the leap bits at:

It wasn't really until 24 hours before that a significant number
of servers were advertising the leap, peaking in the last measurement
before the leap. Interestingly, one server actually advertised a
leap in the wrong direction!

After the leap it looks like more stratum 1 servers were unsynchronised
than usual, though that seems to have setteled down a bit now. The
number of people with the leap bits set is dropping, but isn't quite
zero yet.

I have the peers information from out local ntp server around the
leap.  Our server did the right thing, but it looks like there were
a number of others that didn't. I haven't figured out how to visualise
that yet.