Re: building consensus

2006-06-13 Thread Mark Calabretta
On Mon 2006/06/05 22:04:40 -0400, John Cowan wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

All your points are correct, but it doesn't change the fact that
there was no 1845-12-31 in Manila, any more than there was a
second labeled 2006-04-02T00:02:30 in New York.

There were two such, one labelled EST and the other EDT, neither were
official but either could still be used without ambiguity.  At the
other end of the season there will be two and both will be official.
C.f. email from me dated 2006/01/13 on this subject.

Mark Calabretta


Re: building consensus

2006-06-05 Thread Mark Calabretta
On Mon 2006/06/05 11:07:00 MST, Rob Seaman wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

Julian, just as the Julian succeeded what came before.  That Caesar
was more successful than Pope Gregory at convincing the world to
rapidly adopt the new standard is a result of some pretty interesting
historical differences between the two eras.  The fundamental fact,

... but Pope Gregory was trying to do something harder - effectively to
make the Gregorian calendar retrospective (proleptic) so that Easter
would fall at the right time of year, and this required a calendrical
jump of 11 days.

A simple transition from the Julian leap year rule to the Gregorian rule
(i.e. without calendrical discontinuity) would probably have been more
saleable, especially to people with no interest in Easter.

Mark Calabretta
ATNF


Re: building consensus

2006-06-05 Thread Mark Calabretta
On Mon 2006/06/05 22:04:40 -0400, John Cowan wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

there was no 1845-12-31 in Manila, any more than there was a

As magic tricks go I don't find this one very convincing - I can
clearly see the rabbits behind your back.

Mark Calabretta
ATNF


Re: Risks of change to UTC

2006-01-22 Thread Mark Calabretta
On Sat 2006/01/21 10:11:04 PDT, M. Warner Losh wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

You really should read the archives of this list.  We've been over
this in great detail.  TAI is specifically contraindicated as a time

I don't think new contributors (or even old ones) should have to read
the mountain of email, with its many irrelevant diversions, that has
accumulated over the last 6 years - somewhat over 9MB by my count.

Instead, I (re-)suggest that you (someone) write a position paper, or
at least a FAQ, summarising your points.

Mark Calabretta
ATNF


Re: Risks of change to UTC

2006-01-22 Thread Mark Calabretta
On Sat 2006/01/21 15:15:32 PDT, M. Warner Losh wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

Somewhere around betwee 45,000-80,000 you'll need more than one leap
second a day.

You should recognize this as a reductio ad absurdum argument; at that
time there will be 86401 SI seconds per day - the absurdity being in
continuing to pretend that there are only 86400.

If at that time the number of seconds per day is officially changed to
86401 then the millenia of accumulated quadratic drift will be wiped
away at once and the rate of accumulation of leap seconds reset to zero.

The next step is to ask - what if we increased the official length of
the day before the situation gets so far out of hand, to 86400 plus some
fraction of a second?

Mark Calabretta
ATNF


Re: The real problem with leap seconds

2006-01-18 Thread Mark Calabretta
On Wed 2006/01/18 08:17:54 -, Francois Meyer wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

Maybe it should be,  but  this  is  far  from  being
obvious from its current definition.

I agree that the current definitions leave a lot to be desired in terms
of clarity and rigour - an uncharitable person might even describe the
extract of ITU-R TF.460-6 cited the other day by Michael Deckers as
inconsistent.  However, you have to consider how UTC is actually used in
practice and this is what my comments are based on.

1. UTC and TAI  share  the  same  rate,  the  same
   origin, the same second. And therefore :

UTC - TAI = 0

They both count SI seconds but the question of the origin is a bit
muddy.

You could argue that there is a fixed 10s offset between UTC and TAI
because UTC post-1972 (everything I've said about UTC only applies
post-1972) started with 10 leap seconds, and before 1972 UTC wasn't
simply a representation of TAI.  There's no simple way of fudging
radixes that I can think of to make them match up, but if this worries
you then simply think in terms of proleptic UTC (post-1972),
see http://en.wikipedia.org/wiki/Proleptic.

However, this is not important and really only confuses things further.
(It's why I couched the original example as a graph of a person's age
vs UTC rather that TAI vs UTC.)

2. UTC only differs from TAI by  its  definitions of
   the minute, hour and day.

3. the TAI day, hour, minute are  the  SI
   day, hour, minute  of  86400,3600,60
   SI seconds.

4. the UTC minute is defined  to  ensure  that  dhms
   expressions of UTC match UT1 at .9 s; it  can  be
   either  59,  60  or  61  SI  seconds  long.  This
   definition of the minute is realized
   by  (positive  or  negative)  leap  seconds   and
   ensures that the mean UTC day is the  mean  solar
   day in the long term. The UTC  hour  has  60  UTC
   minutes, the UTC day has 24 UTC hours.

OK, but using the word definition doesn't seem quite right, I'd couch
it in terms based on counting seconds.

If you consulted the wikipedia entry for Factoradic that I referenced
the other day you will see that each digit in the factoradic
representation of a number has a subscript indicating its (fixed) radix.
The fields (not the digits!) of a UTC representation should have
something similar (likewise calendar dates written as 2006/01/19),
except that for the seconds field (and the day field) the radix would
be variable and there's no simple way to write it, so people assume
it's 60 which is what you do anyway if you want your approximation of
UT1.

From that point of view, the sentence from the ITU460-6 :

[UTC] ...differs from it [TAI] from an integer of seconds

should read :

representations of UTC  involving  minutes,  hours,
days differ from equivalent representations  of  TAI
by an integral number of seconds

I agree that the ITU-R TF.460.6 text needs fixing, but I would argue for
a stronger statement emphasising that a UTC representation (of TAI) has
two interpretions, one giving TAI (exact) and the other UT1 (approx), the
latter being offset from TAI by an integral number of seconds.

Mark Calabretta
ATNF


Re: Monsters from the id

2006-01-17 Thread Mark Calabretta
On Mon 2006/01/16 00:40:28 CDT, John Cowan wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

I realize the ALHP has severe problems with this, but I don't approve
of the ALHP anyhow (save perhaps tactically, as explained).

Agreement!

But does anyone think that the leap hour proposal is anything other than
a political device?  If so, please describe in detail how it could/would
work.

Mark Calabretta
ATNF


Re: The real problem with leap seconds

2006-01-16 Thread Mark Calabretta
On Mon 2006/01/16 12:11:04 -, Michael Deckers wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL
 

   UTC (since 1972) is a disseminated timescale that is equal to TAI
   except for additional date and time codes transmitted with the
   signal. These codes indicate the values of TAI - DTAI for each
   full minute of TAI - DTAI.

   In a reading of UTC, (the most recent values of) these date and
   time codes can be taken as is so as to yield a reading that
   approximates UT1. The codes may also be used to derive the value of
   DTAI (from a table of leap seconds since 1972), and thus, to yield
   a reading of TAI. When a timestamp is characterised as UTC
   (rather than TAI), then the first type of reading is implied.

   In order to ensure a unique derivation of TAI from a recorded
   reading of UTC in the vicinity of a positive leap second (where
   DTAI jumps up by 1 s and the value of TAI for a given value of
   TAI - DTAI is not unique), the UTC reading that corresponds to the
   earlier TAI value shall be recorded with a second field = 60 s,
   and the other UTC reading, with a second field  60 s.

   Michael Deckers (still trying to understand the topology you referred to)

I think we are basically on the same wavelength, though I would turn
some of your sentences around.

The way UTC is disseminated is not directly relevant to the discussion,
and I don't think I said anything about topology.  A better way to think
about it would be from the combinatorics point of view.

Enumerative combinatorics is basically concerned with counting things,
usually counting them two ways and drawing conclusions from that.  Use
of mixed-radix numbers is one of the strategies used in combinatorics,
e.g. see http://en.wikipedia.org/wiki/Factoradic.

The representation of UTC as a variable-mixed-radix number is a clever
way (possibly too clever) of counting seconds of TAI in a way that
allows interpretation as either TAI or, approximately, UT1.

The UT1 (or time_t) interpretation is obtained by treating UTC's
representation (label, notation) at face value, as though it was an
ordinary sexagesimal number.  UT1 so derived does have a discontinuity
when leap seconds are inserted and presumably this is what leads people
to say, misleadingly, that UTC itself is discontinuous.

On the other hand, TAI is recovered when the variable radix of the
seconds field is taken into account.  However, since they occur
irregularly, this interpretation requires a table containing the full
history of changes in the radix.  Alternately, the cumulative effect of
the table for epochs since the last leap second is conveniently
summarized in a number that we call DTAI, usually referred to as
TAI-UTC, where UTC here is understood to be the usual mixed-but-
fixed-radix sexagesimal representation.

So there is plenty of scope for confusion.  However, think back to the
graph of age vs UTC that I described at the start of this discussion and
particularly that each instant of the continuous time axis has a unique
UTC representation.

Mark Calabretta
ATNF


Re: The real problem with leap seconds

2006-01-15 Thread Mark Calabretta
On Fri 2006/01/13 14:20:21 -, Michael Deckers wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

   Then why can the IERS express UTC in the MJD notation?

Good point.  The only such usage I am aware of is in IERS Bulletin A
where the MJD column is given without saying even whether it's UTC, TAI,
UT1, or something else.  In fact, in the situation where it's used the
accuracy doesn't warrant it.

Mark Calabretta
ATNF


Re: The real problem with leap seconds

2006-01-15 Thread Mark Calabretta
On Fri 2006/01/13 11:45:13 -, Ed Davies wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

If you don't count the leap seconds then the good news is that
days are all 86 400 seconds long but the bad news is that the
real is undefined during the leap second and there's a
discontinuity (or rather, a surprising continuity in that
at some point it's 23:59:59.99 and a whole second and
a tiny bit later it's 00:00:00.).

Agreed.  I would add that two occasions when you would do this is in
computing UT1 and time_t.

The use of the 23:59:60 notation is described in ISO 8601.
Is it also specified in TF.460?  If so, how do they relate
it to the notion of DTAI?

In practice, refer to the example I gave on Jan/12.

Mark Calabretta
ATNF


Re: The real problem with leap seconds

2006-01-15 Thread Mark Calabretta
On Fri 2006/01/13 16:45:33 -, Michael Deckers wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

   Right, UTC timestamps are ambiguous (in the sense that the

... would have been ambiguous ...

   corresponding TAI value is not known) in the vicinity of
   positive leap seconds, and the notation with a second
   field = 60 s is one (elegant) way to disambiguate.

... had not the variable-radix notation not been introduced.

   Another way to disambiguate is to record the value of DTAI
   together with a UTC (or TAI) timestamp. Such a method is
   standardised in ISO 8601 for denoting offsets from UTC,
   but only with minute resolution. I seem to remember that
   Clive Feather once proposed this for an extension to the
   C programming language.

... where UTC here is taken to be in the usual (fixed-radix) sexagesimal
format.

Mark Calabretta
ATNF


Re: Monsters from the id

2006-01-15 Thread Mark Calabretta
On Fri 2006/01/13 18:39:01 CDT, John Cowan wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

 The situation with the proposed leap hour is quite different.  Given
 that AEST is defined as UTC+1000, and AEDT as UTC+1100, would someone
 care to speculate, in terms similar to the above, what will happen when
 a leap hour is inserted?

Perhaps the two scales will be labeled O.S. and N.S., as our anglophone
antecessors did when switching from Julian to Gregorian.

If you go through the exercise trying to tie leap hours to DST, as I
challenged, you will discover that it raises many questions that are not
addressed by the leap hour proposal.

If you make some plausible assumptions as to how it would operate, with
DST starting and ending at the usual times of year and leap hours
occurring on new year's eve, I believe you will find it far from simple
to do in a rigorous fashion, and that at least one of the timescales is
genuinely discontinuous.

Mark Calabretta
ATNF


Re: Monsters from the id

2006-01-12 Thread Mark Calabretta
On Thu 2006/01/12 02:36:44 CDT, John Cowan wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

We already have that repeated time sequence and gap in much of the world,
and live with it.  These repetitions would be no better and no worse;
when a gap is present, the local sovereignty can omit the gap, but this
is not a necessary feature of the proposal.

At the start of daylight saving where I live the clocks are set forward
from 2am to 3am.  Naively it looks like there is a gap.  Likewise at the
end of daylight saving the hour from 2am to 3am appears to be repeated.

The apparent gaps and repeats are simply an artifact of what happens to
a clock display when you change it to read a different timescale.

Standard time Summer timeLegal time
     --
  2005/10/30 00:01:58 AEST (:   ):
  2005/10/30 00:01:59 AEST (2005/10/30 00:02:59 AEDT)   AEST
  2005/10/30 00:02:00 AEST  -  2005/10/30 00:03:00 AEDT  AEST/AEDT
 (2005/10/30 00:02:01 AEST) 2005/10/30 00:03:01 AEDTAEDT
 (:   ) 2005/10/30 00:03:02 AEDTAEDT
 (:   ) ::
 (:   ) ::
 (:   ) 2006/04/02 00:02:58 AEDTAEDT
 (2006/04/02 00:01:59 AEST) 2006/04/02 00:02:59 AEDTAEDT
  2006/04/02 00:02:00 AEST  -  2006/04/02 00:03:00 AEDT  AEST/AEDT
  2006/04/02 00:02:01 AEST (2006/04/02 00:03:01 AEDT)   AEST
  2006/04/02 00:02:02 AEST (:   ):
  :(:   ):

It should be clear that the gaps and repeats are fictitious, especially
if you think of AEST and AEDT as existing beyond the times when they are
in legal use.  Putting it in practical terms, suppose I have a traffic
accident at 0230 on 2006/04/02, what time will the police officer write
in his report?  For most times of the year he can omit the timezone spec
because there is no legal ambiguity, but to do so for this specific hour
would be insufficient, he must specify AEDT or AEST.

The situation with the proposed leap hour is quite different.  Given
that AEST is defined as UTC+1000, and AEDT as UTC+1100, would someone
care to speculate, in terms similar to the above, what will happen when
a leap hour is inserted?

Mark Calabretta
ATNF


Re: The real problem with leap seconds

2006-01-11 Thread Mark Calabretta
On Wed 2006/01/11 10:47:25 -, Michael Deckers wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

   At some instant when TAI took a value in the positive leap second between
   2006-01-01 + 00 h + 00 min + 32 s and 2006-01-01 + 00 h + 00 min + 33 s
   (the exact instant is not clear from [ITU-R TF.460-6 2002]), DTAI jumped
   from 32 s to 33 s; thus, UTC is not a monotone increasing function of
   TAI either.

Here in a topology-free way is what the axis labels of my graph look
like during the said leap second insertion:

UTC axisTAI axis DTAI
   2005/12/31 23:59:58 2006/01/01 00:00:3032
   2005/12/31 23:59:59 2006/01/01 00:00:3132
   2005/12/31 23:59:60 2006/01/01 00:00:3232
60.932.9  32
60.99   32.99 32
60.999...   32.999... 32
   2006/01/01 00:00:00 2006/01/01 00:00:3333
   2006/01/01 00:00:01 2006/01/01 00:00:3433

The seconds keep step and the graph has no gaps, jumps or kinks.

The only difference between UTC and TAI is one of representation, like
the current year which may be represented as 2006 or MMVI but it's still
the same year.

Mark Calabretta
ATNF


Re: The real problem with leap seconds

2006-01-11 Thread Mark Calabretta
On Wed 2006/01/11 20:58:25 PDT, M. Warner Losh wrote
in a message to: [EMAIL PROTECTED]
and copied to: LEAPSECS@ROM.USNO.NAVY.MIL

: 60.999...   32.999... 32
:2006/01/01 00:00:00 2006/01/01 00:00:3333
:2006/01/01 00:00:01 2006/01/01 00:00:3433
:
: The seconds keep step and the graph has no gaps, jumps or kinks.

Shouldn't the DTAI increment for the leap second?

It goes from 32 to 33 at precisely 2006/01/01 00:00:00 (UTC) (or at
precisely 2006/01/01 00:00:33 (TAI) if you prefer), as shown in the
above table.

Refer to the last page of the current IERS Bulletin A, Vol. XIX No. 1,
ftp://maia.usno.navy.mil/ser7/ser7.dat, which says the same as above
though in a little less detail.

That's the point of
the leap second...  Or is that only needed when you do the POSIX
time_t thing of repeating 59?

My comments on discontinuity etc. do not apply to time_t which is not
the same thing as UTC.

In computer science, regular things are easy.  Irregular ones are hard
and prone to errors.  The :60 kludge makes a regular 1-1 mapping
function for time into a table driven nightmare :-(.

It sure does.

The point isn't that one can construct a 'second labelling' that is
unambiguous, monotonic and increasing, but rather that when one
distills the UTC time down to a single number, you necessarily have
ambiguities and discontinuties in that function.

time_t has ambiguities and discontinuties, but that is not a necessary
consequence of leap seconds.  To their credit the CCIR did not stuff up
in specifying the clock notation to be used for UTC.

Mark Calabretta
ATNF


Re: The real problem with leap seconds

2006-01-09 Thread Mark Calabretta
On Mon 2006/01/09 10:01:27 -, Clive D.W. Feather wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

I've just read through the email that has accumulated on this list since
before xmas - impressive volume!  Why not devote a fraction of that time
and energy to producing a formal position paper.

You've expressed it very badly in the article.

...and you've expressed this rather tactlessly!

The problem is not that UTC
can't be expressed as a real number. Rather (and you do sort of say this,
just not very well), the function UTC(TAI) is not continuous and monotonic.

I can't let this one pass - UTC is continuous and monotonic.  In fact,
ignoring differences in origin, UTC = TAI.  Surprised?  If so then
you're confusing a quantity with its representation (though in good
company in doing so).

First consider a graph of a person's age versus calendar date with a
precision of 1 day.  The fields in calendar dates are mixed-radix, the
day field is also variable-radix depending on the month, and for
February the year, so how should we plot the calendar axis?  Simple, do
it as a count of days and then label it with year, month and day-of-
month; Feb/29 in leap years comes out in the wash.  As expected, the
graph is a continuous straight line of slope 1 - no breaks, no kinks -
the person doesn't age in fits and starts!

Now consider extending this graph to sub-second precision, accounting
for leap seconds, with age to be measured in TAI and calendar date in
UTC.  Now the date axis must be constructed as a count of seconds of UTC
(SI seconds, same as TAI) measured from birth.  As before label the date
axis using conventional calendar/clock notation.  The graph is still a
continuous straight line of slope 1 (no breaks, no kinks).  Leap seconds
are labelled as 23:59:60 - that is the formal representation, each
second of UTC has a unique label as required for mathematical validity.
(Note that it is incorrect to repeat the seconds count at 59, 00, 01 or
anywhere else, even though that may be required on clock displays for
practical reasons.)

Doing arithmetic on UTC using clock notation is like doing arithemetic
on calendar dates or with numbers using Roman numerals.  The principle
difference is that leap days follow a set rule and computations
involving future times can be performed, whereas leap seconds do not
follow a set rule and computations cannot be performed into the future.

I am reminded of a discussion concerning the curious repetition of
1828 in e = 2.718281828...  Simply reexpress the number in base 2,
base e, or something else; the pattern disappears.

Mark Calabretta
ATNF


Re: The real problem with leap seconds

2006-01-09 Thread Mark Calabretta
On Mon 2006/01/09 10:38:54 -, Peter Bunclark wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

I't be interesting to do an FFT on this list, and see if some of the
contributers actually ever sleep, or do any other work...

I had the same thought - the moreso when I reflect on the nil response
to my request for a counter-presentation at ADASS.

(What sort of FFT did you have in mind?)

Cheers, Mark


ABC leapsec article

2005-10-11 Thread Mark Calabretta
The RAS statement seems to have generated quite a bit of media comment:

  http://abc.net.au/science/news/space/SpaceRepublish_1466849.htm

Mark Calabretta
ATNF


Re: Consensus rather than compromise

2005-08-31 Thread Mark Calabretta
On Wed 2005/08/31 07:29:22 +0200, Poul-Henning Kamp wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

If such a system were to be adopted, then in future, in order to
determine a historical time, the full record of timezone changes would
be needed.

How is this different than today ?

To determine the civil time in Copenhagen at a specified epoch we take
UTC, add the timezone offset then possibly add 1 hour for DST.  zoneinfo
provides rules for the latter - e.g. DST starts on the first week of
March and ends whenever.

Currently the timezone offset is essentially fixed for a particular
place, yes there are quirks but it's hardly relevant to the argument.
Under the proposed scheme, timezone offsets would be a function of epoch
as well as place, thus requiring another table for each timezone.

However, there would be a fundamental difference between the DST and TZ
rules: the former are quantized at 0 or +1, so you can only ever get it
wrong by one hour.  However, the TZ offset would not be limited in
range, over millenia it would span many hours, one hour in the first
millenium and accelerating.

John Cowan argues that timezones will tend to coalesce as nations reach
agreement, but remember that we are talking about timescales of
millenia.  Over such times nations as a whole don't tend to reach
agreement - consider how the Gregorian calendar was adopted piecemeal by
different countries (empires really) over centuries.  Consider the way
the map of Europe has changed since the Roman Empire, or even over the
last couple of centuries, or even within our own lifetimes.  And consider
also the disparate and antagonistic nature of political ideologies in
those periods.

But the killer is that a timezone only needs to fragment *once* in order
to require the creation of a separate TZ rule table.

How is it different from having to keep a total history of leapseconds ?

The table of leapseconds is a function of time but not place.

Mark Calabretta
ATNF


Re: Leap seconds BoF

2005-08-31 Thread Mark Calabretta
On Wed 2005/08/31 07:30:17 +0200, Poul-Henning Kamp wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

The closest I'll get is Copenhagen Denmark :-(

If noone can present your arguments in person then we did also invite a
submission.  Given the amount of energy expended on this list (far too
much for me to keep abreast of!) I would have thought that you might
channel some into preparing a few slides.

The example of the GPS device in remote Alaska with the atomic clock
that loses its antenna, given in a later email by M. Warner Losh might
be a good starting point.  Can you guys get together behind the scenes
and do it?  Or must we try to represent your arguments for you?

Mark Calabretta
ATNF


Re: Consensus rather than compromise

2005-08-30 Thread Mark Calabretta
On Tue 2005/08/30 19:46:51 +0200, Poul-Henning Kamp wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

keep the clock as people see it on their wrist [1] in sufficient
sync with the light of day through minor acts of timezone adjustments.

If such a system were to be adopted, then in future, in order to
determine a historical time, the full record of timezone changes would
be needed.  For general purposes, a record would have to be maintained
for every civil administration that sets its timezone (I'm thinking of
/usr/share/zoneinfo).  This would be a much bigger deal than the current
daylight saving switches.

Inevitably it also means that the world's timezones would fragment
as adjacent civil administrations adopted disparate policies on timezone
adjustment.  And then, as the political map of the world changes, so
the record would become ever more hopelessly complicated.

Mark Calabretta
ATNF


Leap seconds BoF

2005-08-30 Thread Mark Calabretta
Greetings, especially to those in favour of stopping leap seconds!

A conference concerning astronomical software is coming up at the start
of October and there will be a discussion forum (BoF) on the leap second
proposals.  The conference (www.adass.org) is mainly directed towards,
and attended by astronomical software engineers, a number of whom have
contributed to this list.

Part of the discussion forum will be to explain the background and
reasons for eliminating leap seconds.  As a co-organizer it occurred to
me that rather than have your views espoused by astronomer-types, who
you may imagine to be biassed, that you may wish to present a summary of
the reasons why you believe leap seconds must be discontinued.

If any of you will be in the vicinity of Madrid in the period Oct/03-05
(the BoF is yet to be scheduled) and would like to give a five to ten
minute presentation then we would be delighted to receive it.  If you
can't attend, but could prepare a half-dozen or so slides (in whatever
format you desire), or perhaps some plain text that can be read out, I
will undertake to present it, verbatim, on your behalf.

As the audience will be scientific/technical in nature, a few well
chosen, specific examples that illustrate the technical aspects of your
argument would be most effective.

Mark Calabretta
ATNF


Re: Precise time over time

2005-08-11 Thread Mark Calabretta
On Thu 2005/08/11 12:37:52 MST, Rob Seaman wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

As far as the maximum permitted size for DUT1 - some think 0.9
seconds is too small.  There appears to be a consensus among quite
divergent thinkers here that 0.9 hours is much too big.  I imagine
most astronomers would be willing to entertain intermediate values.

But, thinking particularly of the piece by Jan Meeus (on this list
recently via Christian Steyaert), I expect that many astronomers would
be quite irritated by that.

However, allowing DUT1 to grow potentially to tens of seconds would be
more patatable than the current leap hour proposal, so a predefined
long-term extrapolation, as described by Steve Allen (Aug/5), seems
possible as a compromise.

However, the question that naturally arises is the required timescale
of the extrapolation.  A figure of 50 years seems first to have been
suggested by Poul-Henning Kamp (Aug/04, My personal opinion is that 50
years seems right, 20 years might be livable) and since seems to have
become set.  However, I question the need for such a long extrapolation.

What systems being constructed now will need to know the time to the
nearest second for 50 years without the possibility of being updated?
Cast your minds back to 1955; the state of technology then; what was
built then that is still running now.  If the extrapolation could be
reduced the potential excursion of DUT1 would also be reduced.  I think
the idea would be much more saleable with an initial timescale of, say,
20 years, extended by 5 years every 5 years.  So at any time the
extrapolation would range between 15 and 20 years.

Mark Calabretta
ATNF


Re: Stupid question from programmer: Why not just eliminate ALL UTC corrections ?

2005-08-04 Thread Mark Calabretta
On Wed 2005/08/03 22:48:35 MST, Scott Moore wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

The conversion to solar time is done for the user's benefit, and that
only needs to be accurate to the second, which is all leap second time
gave you in any case.

Mostly, yes, but it's conceivable that there will be cases (legal/
financial transactions, etc.) where the time needs to be recorded
accurately - assuming that civil/legal time still runs on UTC.  Also,
over the years the accumulated leap seconds will mount to something
significant - a lot more than 24s.  Therefore, I believe it would be
best to implement procedures to handle this conversion correctly from
the start.  Anyway, I agree with your basic point that system time be
maintained in TAI.

Mark Calabretta
ATNF


Re: Stupid question from programmer: Why not just eliminate ALL UTC corrections ?

2005-08-04 Thread Mark Calabretta
On Thu 2005/08/04 08:18:55 +0200, Poul-Henning Kamp wrote
in a message to: LEAPSECS@ROM.USNO.NAVY.MIL

Most if not all modern UNIXes already have the table of leapseconds.

Without wishing to imply that the solution is so simple, your answer
begs the question: what do you see as the principle difficulty in
having systems use TAI internally and maintain a table of leap seconds
for conversion to/from civil time?

Mark Calabretta
ATNF


Asian earthquake effects

2005-02-10 Thread Mark Calabretta
May be of interest to this list:

ASIAN QUAKE MOVED ISLANDS, SHORTENED DAYS (Environment  Nature News,
9/2/05)
The massive earthquake that triggered the Asian tsunami wobbled the Earth on
its axis, forced cartographers back to the drawing board and changed time by
a fraction. But there's no need to adjust your clocks.
http://www.abc.net.au/science/news/enviro/EnviroRepublish_1299077.htm

Mark Calabretta
ATNF


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



Leap-seconds, the epsilon perspective

2003-01-28 Thread Dr. Mark Calabretta
 scale - computer
  programmers happy!

   4) Cumulative effect of epsilon replaced by a small daily
  correction - grandchildren's grandchildren happy!

   5) No legislative changes required - politicians happy!

   6) No effect on religious or sporting calendars - religious and
  sporting communities happy!

   7) Conceptual simplicity - everyone happy!!

Why might this not be such a good idea?

   1) Leap-second updates replaced by Epsilon updates - user
  intervention still required (unless non-secular changes in
  epsilon are ignored).

  However, the error introduced by a missed, or delayed update
  would be much less, only a small fraction of a millisecond per
  day (cumulative).

   2) UTC still not predictable indefinitely into the future (unless
  non-secular changes in epsilon are ignored).

   3) The difference between TAI and UTC would no longer be an
  integral number of (leap) seconds.

  Historical time calculations would be a little more complicated
  (unless non-secular changes in epsilon are ignored) because the
  value of Epsilon and its date of introduction would have to be
  recorded, rather than just the date of introduction of a leap-
  second.

   4) While digital clock displays would handle this system easily,
  analogue clock faces (even if digitally driven) might have
  trouble once epsilon exceeds a few seconds - but that is a long
  way off.

   5) Burden falls on precision clockmakers, and timekeeping software.

Why wasn't this done from the start?

   I believe that the secular deceleration of the Earth's rotation
   rate was unknown, or poorly understood, in the early 1970s when
   UTC was introduced.

   Also at that time, clocks were not smart enough to handle this sort
   of correction, but now that they are driven by those new-fangled
   (in 1970s terms) micro-processors it should be relatively easy to
   implement.

   Analogue clock faces would have been the norm in the early 1970s,
   adjusting them for leap seconds would have been simpler.

What would be the timescale for such a change?

   Many clocks (e.g. GPS Time and the clocks at most astronomical
   observatories) would maintain their best approximation of TAI
   and software would compute UTC from it using tabulated values of
   Epsilon (or computed values if non-secular changes in epsilon are
   ignored).  Other clocks might maintain UTC directly using the
   current value of Epsilon.  Either way, the clock and/or software
   would need changing.

   Costs would be minimized if the change was incorporated as part of
   the replacement cycle of precision clocks and timekeeping software.
   Thus, it depends largely on what the lifetimes of these are;
   ideally, all such should have been replaced by the time the change
   was introduced.

   Thus we may be looking at a multi-decade lead-in.  However, there
   is no rush!

What would we tell the public?

   The Earth is slowing down (friction - sort of) and the days are
   getting very slightly longer, but you don't have to worry about
   it unless you need to know the time of day to within a few
   milliseconds.  In particular, Ramadan, Diwali, Pesach, Easter,
   Hanamatsuri, the World Cup, etc. are not affected, nor are
   world timezones.

And the *really* long term?

   Millions of years hence, when the mean solar day is 25 SI hours
   long, epsilon would be one hour but UTC would still function
   properly.  Notably, updates to Epsilon would be as infrequent
   as ever.

   However, the world's timezones, especially those furthest from
   Greenwich, would need a modest adjustment - half an hour at most.


Dr. Mark Calabretta
Australia Telescope National Facility