Re: [LEAPSECS] interoperability

From: Poul-Henning Kamp <phk_at_phk.freebsd.dk>
Date: Mon, 09 Jan 2006 08:06:04 +0100

In message <FD001FC7-7A1F-46FD-BF11-675092867153_at_noao.edu>, Rob Seaman writes:

>> Sensibly designed operating systems keep time in the form of the
>> first stage clock,
>
>Perhaps. We have no examples of this. Stage one would be TAI. As
>we have just been reminded, TAI is "not ready for prime time".

Stop.

You yourself defined stage one as "TAI with some constant offset"
yourself, you can't change definition in the middle of the discussion.

Stage one is something like GPS time or UTC with no further leap
seconds.

Today stage one is UTC with leapseconds and all POSIX systems use
that but fake the leapseconds.

>> Badly designed operating systems keep time in local time which
>> makes interchange of information a nightmare across timezones.
>
>You are arguing apples and oranges. These operating systems, in
>effect, use "stage three" clocks.

No, you are confused.

>Perhaps I miss your meaning here, too. The event of migrating a time
>zone is a discontinuity just as with a leap second or leap hour.

The discontinuity is not in the stage one timezone, but only in the
governmental offset which defines stage two relative to stage one.
We already have two of those discontinuitues a year most places and
people and computers can live with them.

People can live with them because they are big enough that you
don't forget about them (for long). Computers can live with
them because they use the stage-one timescale for representation.

>> Denmark spans only a few hundred kilometers from east to west (not
>> counting Greenland this time), yet sunrise and sunset varies about
>> 30 minutes from one side to the other.
>
>This is true. It is irrelevant to the underlying international
>clock. These are simply constant (if position dependent) offsets.
>Big wup. I think this issue is confusing the discussion.

No, they are actually very relevant because they show that you can't
use a timescale as a vector component to locate extra terrestial
objects without taking your longitude into account.

>daylight saving time is irrelevant.

No.

>What matters is not when sunrise occurs, but rather that every day
>has one (and only one).

DST is very relevant, as it is a much more feasible mechanism
for holding the sun high in the sky on the civil timescale.

>> Conversion from stage two to stage one (and back) is perfect,
>
>Don't believe a detailed enough proposal is on the table to either
>define the meaning of "perfect" in this context, or determine if the
>notion being discussed meets the requirements for being so regarded.

"I don't belive in science" ?

For any timestamp on the civil timescale any spot on earth, there
exist a mathematical formula which will convert that timestamp
to UTC and vice versa.

>> If Denmark or Elbonia decides to use a timezone which is offset
>> from stage one by 1h3m21s, then it still works,
>
>Again, what is "it", precisely?

Your own proposal.


> stage one is atomic time (e.g., TAI)
> stage two is international civil time (e.g., UTC)
> stage three is local legal time (e.g., Mountain Standard Time)

No.

Now you try to change definitions under the discussion again.

In your first email you defined it thusly:

> Without further debating the meaning of "civil time", consider the
> implications of this two stage system. The first stage conveys TAI
> or something related to it by a constant offset. The second stage at
> any location (correct me if I misunderstand you) would be a secondary
> clock disseminated at the direction of the local authorities.

In other words:

        (stage_zero is TAI)
        stage_one is TAI + constant
        stage_two is stage_one + governmental adjustment.

>> In a couple of hundred years, the Danish Parliament (or its
>> successor in interest) will simply decide "from YYYY-MM-DD HH:00,
>> the Danish Civil time will use offsets -3h and -2h (instead of
>> presently -1h/-2h) and the transition will happen on the switch
>> from summertime to wintertime by _not_ adjusting the clock".
>
>The only way this differs from the leap hour proposal is that you are
>assuming that different localities can (or would) carry these
>adjustments out separately.

I've never been in favour of the leap-hour proposal as other than
a political instrument to be abandonned well before the clock strikes.

And yes, I think you are likely to see far more governments fiddle
with their respective civil time than scientists fiddle with UTC
over the next 500 years, so I'm confortable leaving it to them.

>A fall back event means that the clock (local, standard,
>international, whatever clock you want) first traverses an hour - and
>then traverses it again.

No, that's what happens every year when switch from summer time to
winter time.

When the need to "reset" the civil timescale that event does _not_
happen.

>This doesn't work because we're on the
>wrong side of the pendulum's arc. The point being that you don't
>need to *not* adjust the clock in the Autumn - you need to not adjust
>the clock in the Spring.

Same argument: Not adjusting the clock is less disruptive than
doing so, no matter which half of the year.

>(We'll omit discussion of the fact that not all localities observe
>daylight saving time in the first place.)

They have 600 years to find a solution and an implementation
date for it.

>...but isn't what you are asserting precisely equivalent to saying
>that you are willing to support the issuance of one or more leap
>seconds - per day? If this will be "more suitable" a couple of
>thousand years from now - why not now?

No, I won't entertain such a notion. I seriously plan to not be
a nuisance to the world long before that.

And I happen to think that my (n)great-children should get to
decide for themselves about how to do timekeeping, and I am
sure that they will think so themselves.

--
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 Sun Jan 08 2006 - 23:16:57 PST

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