[LEAPSECS] Fwd: Leaping onward

[Rob Seaman]

The last few issues of the RISKS Digest have had leap seconds repartee:

	http://catless.ncl.ac.uk/Risks/24.89.html#subj13
	http://catless.ncl.ac.uk/Risks/24.90.html#subj18

(And referencing back to http://catless.ncl.ac.uk/Risks/ 
24.79.html#subj3 with some messages in between.)

The discussion began to stray a bit from the mission of RISKS, but  
perhaps can generate boisterous banter here.

Rob Seaman
National Optical Astronomy Observatory
--

Begin forwarded message:


> From: RISKS List Owner <risko at csl.sri.com>

> Date: November 6, 2007 2:26:38 PM MST

> To: Rob Seaman <seaman at noao.edu>

> 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 <dot at dotat.at>

> To: RISKS List <risks at csl.sri.com>

> cc: Rob Seaman <seaman at noao.edu>, Tony Finch <dot at dotat.at>

> Subject: leap hours

> In-Reply-To: <CMM.0.90.4.1194041084.risko at chiron.csl.sri.com>

>

>> Date: Thu, 25 Oct 2007 13:43:30 -0700

>> From: Rob Seaman <seaman at noao.edu>

>> 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  <dot at dotat.at>  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. 

> 4.64.0711031449210.12530 at hermes-1.csi.cam.ac.uk>

> Cc: Tony Finch <dot at dotat.at>

> Content-Transfer-Encoding: 7bit

> From: Rob Seaman <seaman at noao.edu>

> Subject: Re: leap hours (and RISKS of Daylight Saving)

> Date: Mon, 5 Nov 2007 11:50:42 -0700

> To: RISKS List <risks at csl.sri.com>

>

> 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 <seaman at noao.edu>

>>> 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 <dot at dotat.at>

> To: Rob Seaman <seaman at noao.edu>

> cc: RISKS List <risks at csl.sri.com>, Tony Finch <dot at dotat.at>

> Subject: Re: leap hours (and RISKS of Daylight Saving)

> In-Reply-To: <1A27AAEB-8DD5-4BCB-B15D-AFCFF4789A53 at noao.edu>

>

> 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  <dot at dotat.at>  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 <risks at csl.sri.com>, Steve Allen <sla at ucolick.org>

> From: Rob Seaman <seaman at noao.edu>

> Subject: Re: leap hours (and RISKS of Daylight Saving)

> Date: Tue, 6 Nov 2007 12:03:33 -0700

> To: Tony Finch <dot at dotat.at>

>

> 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