[LEAPSECS] (no subject)

[Steve Allen]

> In addition to what John Cowan said, I'd also point out that planning

> is the one of the biggest issues with leap seconds.

>

> In terms of planning for the future, if an application cares about

> local time, not knowing whether a leap second is going to happen

> outside a six month window can be a much larger problem than handling

> sliding time zones that would happen much less frequently and, one

> would think, with considerably more advance notice.

>

> For those that are in favor of the current system of leap seconds, it

> might be more effective to pretend that people don't have to plan for

> the future than to remind them in the opening sentence.



Please identify the operations which need one second predictability
over a time span of six months.  They can't be scheduling a meeting,
for a time zone change might be decreed.  They can't be launching  
shuttle
to rendezvous with ISS, for the solar activity will drag the atmosphere
by more than that much.
What are these applications?

For these operations please explain why the timing demands of the
system did not already recognize that they needed to design a
GPS time receiver into the applications.  (As we've just read, the
geodecists recognized that the technical aspects of using GPS
outweighed any bureaucratic mandate to use a time scale with an
international recommendation behind it.)

And to the more general audience than John Hein...

Please explain why using the name UTC for something with different
characteristics and applications is more important than the history
and art embodied in Dennis di Cicco's analemma
http://www.twanight.org/newTWAN/photos.asp?ID=3001422

Please explain why changing the name of the broadcast time scale
to TI and putting UTC and the leap seconds into zoneinfo does
not satisfy all requirements of the need for uniform time scale.

Please explain why the recommendations of the assembly of world
time experts at Torino in 2003 are not valid even after it has
been pointed out that zoneinfo provides a mechanism for implementing
them.

If the objections are about presumptions of computer code with respect
to scheduling something for the same civil time tomorrow please identify
code systems which correctly implement the sorts of things seen here
http://www.webexhibits.org/daylightsaving/g.html
and discuss the relative number of systems which already get it wrong.

I want to know why I should give up the notion of civil time being
based on mean solar time, for myself and for posterity.

--
Steve Allen                 <sla at ucolick.org>                WGS-84  
(GPS)
UCO/Lick Observatory        Natural Sciences II, Room 165    Lat   
+36.99855
University of California    Voice: +1 831 459 3046           Lng  
-122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m