[LEAPSECS] Lets get REAL about time.

[Rob Seaman]

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