Re: [LEAPSECS] The real problem with leap seconds

From: Neal McBurnett <neal_at_BCN.BOULDER.CO.US>
Date: Sat, 7 Jan 2006 12:20:23 -0700

On Sat, Jan 07, 2006 at 04:02:04PM +0100, Poul-Henning Kamp wrote:
> In message <43BFD037.5050208_at_edavies.nildram.co.uk>, 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
> complications.

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
> seconds.

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."
[http://www.ien.it/luc/cesio/itu/annex_a.pdf]

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

Neal McBurnett http://bcn.boulder.co.us/~neal/
Signed and/or sealed mail encouraged. GPG/PGP Keyid: 2C9EBA60

> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> phk_at_FreeBSD.ORG | TCP/IP since RFC 956
> FreeBSD committer | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
Received on Sat Jan 07 2006 - 11:20:49 PST

This archive was generated by hypermail 2.3.0 : Sat Sep 04 2010 - 09:44:55 PDT