From: RISKS List Owner <[EMAIL PROTECTED]>
Date: November 6, 2007 2:26:38 PM MST
To: Rob Seaman <[EMAIL PROTECTED]>
Subject: Leaping onward
Is there anything here that you feel would be worth summarizing
tersely for
RISKS, or should we just blow the whistle?
---------------
1) 3-Nov Tony Finch < leap hours (3460 chars)
2) 5-Nov Rob Seaman < Re: leap hours (and RISKS of Day (4310
chars)
3) 5-Nov Tony Finch < Re: leap hours (and RISKS of Day (3735
chars)
4) 6-Nov Rob Seaman < Re: leap hours (and RISKS of Day (16780
chars)
Message 1 -- *********************
Date: Sat, 3 Nov 2007 14:58:28 +0000
From: Tony Finch <[EMAIL PROTECTED]>
To: RISKS List <[EMAIL PROTECTED]>
cc: Rob Seaman <[EMAIL PROTECTED]>, Tony Finch <[EMAIL PROTECTED]>
Subject: leap hours
In-Reply-To: <[EMAIL PROTECTED]>
Date: Thu, 25 Oct 2007 13:43:30 -0700
From: Rob Seaman <[EMAIL PROTECTED]>
Subject: End of Leap Seconds? (Re: RISKS-24.79)
Earlier suggestions for embargoing leap seconds relied on the
flabby idea of
leap hours. The leap hour concept appears to rest on the notion
that many
localities manage to handle one hour Daylight Saving Time shifts
twice a
year. Perhaps the thought is simply that a year will come when
one of the
DST jumps is skipped...unfortunately, it doesn't work like that.
(And not
only because not all localities observe DST, and not all at the
same time.)
The precise reason that DST is an acceptable timekeeping policy is
that any
civil or legal entities or systems that need to know an
unambiguous time can
fall back on a common worldwide UTC. It would be completely
inappropriate
to institute a leap in UTC by resetting the clocks to run through
the same
hour twice. How could one disambiguate that hour of world history
ever
after?
The obvious answer is to leave UTC alone, even when it is an hour
or more
away from GMT. If the discrepancy becomes inconvenient for civil
purposes
then local time offsets can be adjusted. Local time changes do not
need to
be agreed globally and they do not need to be applied simultaneously
around the world. Therefore no new mechanism or policy is needed to
cope
with a continuous UTC.
Tony.
--
f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/
FORTIES CROMARTY: NORTHWEST, BACKING SOUTHWEST LATER, 5 OR 6,
DECREASING 3 OR
4. MODERATE OR ROUGH. SHOWERS. GOOD.
Message 2 -- *********************
In-Reply-To: <Pine.LNX.
[EMAIL PROTECTED]>
Cc: Tony Finch <[EMAIL PROTECTED]>
Content-Transfer-Encoding: 7bit
From: Rob Seaman <[EMAIL PROTECTED]>
Subject: Re: leap hours (and RISKS of Daylight Saving)
Date: Mon, 5 Nov 2007 11:50:42 -0700
To: RISKS List <[EMAIL PROTECTED]>
This suggestion has been made before on the LEAPSECS mailing list:
http://six.pairlist.net/mailman/listinfo/leapsecs
A brief (negative) response is to consider that computer scientists
have raised all this ruckus over the need to track a single list of
historical leap second events. However, leaving the question to
local officials replaces that single list with hundreds, or
potentially thousands, of such lists that our software systems would
need to consult. The possibility for second-scale errors in a single
list would be replaced with the permanent likelihood of hour-scale
errors in multiple geographically entangled lists. Time would be
tied back to municipal timekeepers as it was before the standard
timezones were laid down. This is the opposite of the policy sought
by the centralized precision timekeeping community.
Also consider reports like http://www.physorg.com/
news113282110.html. The disruptions caused by unexpected Daylight
Saving Time style jumps are not the best model for establishing safe
civil timekeeping practices.
Rob Seaman
National Optical Astronomy Observatory, Tucson, AZ
--
On Nov 3, 2007, at 7:58 AM, Tony Finch wrote:
Date: Thu, 25 Oct 2007 13:43:30 -0700
From: Rob Seaman <[EMAIL PROTECTED]>
Subject: End of Leap Seconds? (Re: RISKS-24.79)
Earlier suggestions for embargoing leap seconds relied on the
flabby idea of
leap hours. The leap hour concept appears to rest on the notion
that many
localities manage to handle one hour Daylight Saving Time shifts
twice a
year. Perhaps the thought is simply that a year will come when
one of the
DST jumps is skipped...unfortunately, it doesn't work like that.
(And not
only because not all localities observe DST, and not all at the
same time.)
The precise reason that DST is an acceptable timekeeping policy is
that any
civil or legal entities or systems that need to know an
unambiguous time can
fall back on a common worldwide UTC. It would be completely
inappropriate
to institute a leap in UTC by resetting the clocks to run through
the same
hour twice. How could one disambiguate that hour of world history
ever
after?
The obvious answer is to leave UTC alone, even when it is an hour
or more
away from GMT. If the discrepancy becomes inconvenient for civil
purposes
then local time offsets can be adjusted. Local time changes do not
need to
be agreed globally and they do not need to be applied simultaneously
around the world. Therefore no new mechanism or policy is needed to
cope
with a continuous UTC.
Tony.
Message 3 -- *********************
Date: Tue, 6 Nov 2007 00:45:05 +0000
From: Tony Finch <[EMAIL PROTECTED]>
To: Rob Seaman <[EMAIL PROTECTED]>
cc: RISKS List <[EMAIL PROTECTED]>, Tony Finch <[EMAIL PROTECTED]>
Subject: Re: leap hours (and RISKS of Daylight Saving)
In-Reply-To: <[EMAIL PROTECTED]>
On Mon, 5 Nov 2007, Rob Seaman wrote:
A brief (negative) response is to consider that computer
scientists have
raised all this ruckus over the need to track a single list of
historical leap second events. However, leaving the question to
local
officials replaces that single list with hundreds, or potentially
thousands, of such lists that our software systems would need to
consult.
The Olson TZ database already exists and works - at least it does
to the
extent that is allowed by politicians mucking around. This is a
distinct
contrast to leap second handling code which is either unused or
broken.
TZ code gets tested all the time and the database is updated many
times
each year. It's much more difficult to test the promulgation and
implementation of leap seconds. You probably remember the discussions
about the various failures of the leap second at the end of 2005.
I agree with you that the leap hour proposal is broken, but for a
different reason: any limit on DUT1 leads to unpredictable disruptions
in our timekeeping infrastructure. It is wasteful to have two
mechanisms
for dealing with the offset between atomic time and civil time: one
gross
(time zones) and one fine (leap seconds), especially when the
inaccuracy
and arbitrariness of one overwhelms the delicacy of the other. If
the fine
tuning mechanism gets bodged into another gross adjustment
mechanism, it
should become apparent that it's entirely redundant by the time a leap
hour would be needed.
Tony.
--
f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/
BAILEY: NORTHWEST BACKING WEST OR SOUTHWEST 6 TO GALE 8,
OCCASIONALLY SEVERE
GALE 9. VERY ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD.
Message 4 -- *********************
Cc: RISKS List <[EMAIL PROTECTED]>, Steve Allen <[EMAIL PROTECTED]>
From: Rob Seaman <[EMAIL PROTECTED]>
Subject: Re: leap hours (and RISKS of Daylight Saving)
Date: Tue, 6 Nov 2007 12:03:33 -0700
To: Tony Finch <[EMAIL PROTECTED]>
Hi Tony,
I fear we're moving beyond what our moderator would consider the
realm of RISKS. I've replied to a few points in your message,
perhaps PGN can extract something pertinent. As you know, the
LEAPSECS list provides a forum for discussions broader than risks,
per se.
On Nov 5, 2007, at 5:45 PM, Tony Finch wrote:
On Mon, 5 Nov 2007, Rob Seaman wrote:
A brief (negative) response is to consider that computer
scientists have raised all this ruckus over the need to track a
single list of historical leap second events. However, leaving
the question to local officials replaces that single list with
hundreds, or potentially thousands, of such lists that our
software systems would need to consult.
The Olson TZ database already exists and works - at least it does
to the extent that is allowed by politicians mucking around.
The essence of the limitations encountered while trying to work
around the problem using moveable timezones is precisely the
multiplicity of political actors.
TZ code gets tested all the time and the database is updated many
times each year.
As you said on LEAPSECS:
On Dec 26, 2006, at 10:10 AM, Tony Finch wrote:
On Mon, 25 Dec 2006, Keith Winstein wrote:
Even if a program is able to calculate TAI-UTC for arbitrary
points in the past and near future, what should a library do when
a program asks to convert between UTC and TAI for some instant
further than six months in the future?
You should treat this kind of conversion in the same way that you
treat local time zone conversions, which are also unpredictable.
The shifting timezone approach would make the past as unpredictable
as the future. The current TZ database does not appropriately
persist the history of prior timekeeping rules. It is daunting to
consider designing a system to do so centuries into the future
through all intervening geopolitical upheavals. This would be
exceptionally more complex than simply complying a common list of
leap seconds.
The notion of trying to work around the reality of two different
kinds of time (interval and Earth orientation) by gimmicking the
timezones translates a single requirement on one central authority
into many evolving requirements on a parade of nation-states that may
be yet to even exist.
You probably remember the discussions about the various failures of
the leap second at the end of 2005.
What I remember is that these were trivial and insignificant. The
purported cure is worse than the supposed disease.
I agree with you that the leap hour proposal is broken,
Let's emphasize that point - two people with very different views of
the problem agree that leap hours are not the solution.
In general, solutions are being entertained before the problem has
been stated - before the use cases are outlined - before the system's
requirements are discovered. There isn't even a coherent notion of
who the stakeholders are.
Whatever the ultimate solution, this is clearly a lousy basis for
making policy decisions.
Rob Seaman
National Optical Astronomy Observatory, Tucson, AZ
