"Olson, Arthur David (NIH/NCI)" wrote on 2004-03-02 14:38 UTC:
The 2004-03 issue of the U.S. monthly "Discover" has an article titled "Leap Seconds" by Karen Wright(pages 42-45, but the first two pages are décor and an introductory blurb).
Links to 10 further recent mass-media articles on the leap second are collected at the end of http://www.cl.cam.ac.uk/~mgk25/time/leap/
also notes a couple of modest proposals: "Leap seconds could be inserted every four years along with the February leap day...or leap minutes could be added every half century or so." (Either proposal, if adopted, would require changes in both POSIX and the public-domain time zone code.)
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.
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.
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. 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. Markus -- Markus Kuhn, Computer Lab, Univ of Cambridge, GB http://www.cl.cam.ac.uk/~mgk25/ | __oo_O..O_oo__