Tony Finch wrote:
> It is already commonplace.
Well, no. The geographic center of California is about exactly 8 hours (120
degrees) west of Greenwich. Los Angeles is a couple of degrees East and San
Francisco a similar distance West of this meridian. Even for California plate
tectonics can be ignored, and PST will always remain naturally 8 hours from GMT.
Both PST and GMT are stationary with respect to Universal Time. Historians or
futurists, scientists or other long term planners can predict the relative
activities in these two places on a given future calendar date, or
proleptically backwards indefinitely even over periods that the length-of-day
varies, precisely because it is days that are being counted.
If Coordinated Universal Time is redefined, the foundation of this trembles.
For a given UTC we would no longer even be able to predict the day it
corresponds to, hence Steve Allen's comment:
The effect of this proposal is not about clocks, but rather to
disconnect the count of calendar days from the sun.
It is - let's see, what's an appropriately technical term - "wacky" to
encourage the timezone system to become unglued from the Earth.
Both the ITU and US statements last week focus on "continuous time" as their
continuing goal. This phrasing is troubling since as has been emphasized here
UTC has always been precisely that: continuous. Putting that aside for the
moment the question is how to reach a consensus that won't dump us right back
in the current mess when the issue next comes up in 2015.
Whatever the design parameters of new APIs, e.g., floating-point or not, they
will only succeed if the underlying conceptual model resembles the real-world.
Steve Allen's concept of how such interfaces should interact with the system of
timezones:
http://www.cacr.caltech.edu/futureofutc/preprints/45_AAS_11-681_Allen.pdf
is 1) written down and has references, and is 2) conformant with the
real-world. On the other hand, the timezone assumptions underlying the "Draft
Revision to ITU-R Recommendation TF.460-6" are neither. We need to revise the
revision.
Rob
_______________________________________________
LEAPSECS mailing list
[email protected]
http://six.pairlist.net/mailman/listinfo/leapsecs
