On Wednesday, Mar 3, 2004, at 03:17 Australia/Sydney, Markus Kuhn wrote:
In the ITU SRG 7A group that currently deliberates the future of UTC, these proposal have already been rejected as being impractical, more than a year ago. The only proposal left on the table is to drop leap seconds forever. This would detach the international reference time (currently called UTC) from the rotation of the Earth. The point where the new international reference time [the proposal calls it Temps International (TI)] would correspond to local mean solar time would very slowly accelerate eastwards, starting from Greenwich. One specific proposal is to replace UTC with TI in 2022 (50th birthday of UTC). At that time, UTC and TI will be identical, but TI will be a physical (that is based on the SI second, not on the angle of the Earth) time without leap seconds. TI is just TAI plus an offset for smooth transition in 2022. Local civilian times would be defined relative to TI, which takes over this role from UTC. UTC would no longer be maintained. Their TI offset of local civilian time zones would have to change every couple of hundred years to keep local civilian times in +/-1 h sync with daylight, but as well all know, local civilian times change far more frequently for political reasons anyway. These LCT changes could easily be implemented by dropping the repeated hour at the end of summer time every few hundred years (the first one in around 2600) in those time zones that have it.
That would destroy the constant (plus of minus a fraction of a second) relationship between a maintained timescale and mean solar time at a given longitude. I could no longer look at a map (with longitude lines) and know immediately what local mean solar time is (just about exactly, at least where the longitude lines are). That would be sad, if nothing else.
Your correspondent's two cents: in setting up the time handling in UNIX, T&R got it exactly right with respect to springing forward and falling back when DST goes in to and out of effect--keep the computer counting monotonically and leave it to the software to translate the monotonic count into a representation of local time. What's right at the level of an hour is also right at the level of a second--keep the computer counting at one count per second, and leave it to software to figure out what should be displayed when the user asks what time it is.
Hear, hear! Bravo!
I don't agree. There is the important difference that UTC is today very widely disseminated, whereas TAI is a curiosity only known to time geeks like us. Keeping a computer synched to something like TAI would only be practical in the real world if a leap-free timescale (e.g., the existing TAI or GPS time) were widely enough available, along with a regularly updated UTC-TAI offset table. Current time distribution services, however, provide only UTC in easily accessible form, therefore running machines in TAI would likely cause them to get the leap second offsets wrong due to out-of-date leap-second tables rather quickly. Their timestamps would quickly get an integer number of seconds wrong relative to the timestamps of machines with up-to-date leapsecond tables.
1: Stop time distribution services from providing UTC and get them providing TAI instead. 2: Estimate and publish leap-second dates 30, 40, or 50 years in advance, thus maintaining a table of offsets for that many years into the future at all times. Poor estimates could be corrected later. The only casualty of this would be the sub-second difference between UTC and UT1 (or whichever it is). Yes, my quick inference of mean solar time from longitude would be slightly less accurate. And software will need to be updated anyway; lead time could be decades.
In the present scheme of how we define local civilian times (namely relative to UTC), I believe that what POSIX does (namely making time_t an encoding of what a UTC clock displays) is the most practical compromise. It needs a bit fudging near a leap second but works reliably the rest of the time, without a need to maintain long-term state (leap-second tables). In case the TI proposal gets implemented, the problem would be gone, and the only long-term problem would be that TI and local times drift apart without limit in the long term. But it will be several millenia before the difference even reaches a single day, at which time the Gregorian calendar will have gone well beyond its best-before-date as well. Tables like tzdata with offsets between the international reference time and the LCTs would have to be maintained and updated in either case, but they are, in most parts of the world, much more stable than leap second tables.
See 2 above. The calendar could also be the subject of similar treatment, substituting leap seconds with leap days and years (in advance) with centuries or millennia. Alex LIVINGSTON