That would be a disaster. I have recently finished a contract where I had an insight into the comms used for financial dealings. The clocks used by the banks, traders, financial exchanges etc are GPS synchronised and many users start getting very agitated when their messages take an additional 100 ms to be transmitted. Using "Unix time" as described by John would not work.
_____ From: [email protected] [mailto:[email protected]] On Behalf Of John M. Steele Sent: 08 July 2011 13:38 To: U.S. Metric Association Subject: [USMA:50838] Re: Stretching the second There have also been proposals that "Unix time" beat slowly either all day or for the last few hours on "leapsecond day" to have 86400 "modified seconds," while "leap second day" has 86401 SI seconds. I think what is required is recognition that UTC and civil time are not the end-all-be-all. Keep TAI, and then maintain TAI offsets for UTC and any other civil times. The rules may change but the possibility of leap seconds and daylight savings are predicted. The systems need to be able to preprogram the occurence instance and handle them automatically. The requirement needs to be in the specification and the supplier needs to demonstrate compliance. Leap hours kick the can down the road 500 years, ensuring 499 years of non-compliance, followed by panic. _____ From: Martin Vlietstra <[email protected]> To: U.S. Metric Association <[email protected]> Sent: Fri, July 8, 2011 6:56:58 AM Subject: [USMA:50837] Re: Stretching the second There was also a proposal to abandon leap seconds and introduce leap hours instead. This would effectively have kicked the issue into the long grass for 800 years. About fifteen years ago I worked on a police crime recording computer system. The civil servants from the police force specified that daylight saving should be effected by speeding up and slowing down the computer clock rather than a step change. The problem was that the database system could not handle such a mechanism, the development was too far down the line to do the job properly, so in the end they stopped the computer system at the start and end of daylight saving and when the clocks went back, the computer system was off the air for an hour. _____ From: [email protected] [mailto:[email protected]] On Behalf Of John M. Steele Sent: 08 July 2011 11:04 To: U.S. Metric Association Subject: [USMA:50834] Re: Stretching the second Those who forget deserve to repeat history, or something like that. "Second-stretching" was already tried from 1960 to 1972. While one atomic clock kept TAI, another was "steered" to drift from it at a controlled rate to approximate UT2, and the "steering constant" was declared for six months or so at a time. That still wasn't perfect, and they declared mini-leaps of 50 or 100 ms. A total of 10 leap seconds were added in this manner before the present scheme was launched in 1972. That scheme was considered too complex and unwieldy and the present scheme was viewed as an improvement in 1972. Anyone advocating a return to yesteryear should explain in detail while it will work better now. (it won't, enough said.) The other scheme I've seen proposed is leap-minutes or leap-hours. Those would obviously occur at about 1/60 or 1/3600 the random rate of leap seconds. That greater infrequency would lead to systems being LESS well designed to accomodate them in my opinion. IERS provides notification (Bulletin C) of the plan for a leap second with approximately 5 months advance notice of the actual leap second, which is always scheduled for the end of June or December. While longer intervals would be prefereable to "second stretching," I am convinced that those who fail to plan their systems for leapseconds would forget to plan for leapminutes. If earth rotation drifts further so that more than 1 leapsecond per year is required, the second choice is end of March and September, and third choice, the end of any month. Any system that is based on accurate time should either keep TAI or recognize that a leap second can be declared with advanced notice at the end of every month and operate a mechanism of obtaining that advance notice. I would note that most "atomic clock" products which receive radio time signals from WWB correctly decode and implemnent the leapsecond, and that NIST makes the notification available in their Internet time protocol as well (with less advanced notice). The GPS system keeps "GPS time" which is a fixed offset to TAI and broadcasts the differential leap second count in the navigational message. _____ From: James Frysinger <[email protected]> To: U.S. Metric Association <[email protected]> Sent: Thu, July 7, 2011 10:16:21 PM Subject: [USMA:50831] Stretching the second Folks, You might find this article of some interest. It reports an effort made by some people to convince the ITU (formerly, International Telegraph Union) to change the way that UTC is calculated, probably by departing from the "atomic second" as they call it -- actually, the unit second as defined by the SI. At least that's my reading of the article. Since all "leap seconds" have been positive, I suppose that amounts to them wanting to stretch the second, so to speak. Keep in mind, these are radio and TV folks, not metrologists most likely. My guess is that the ITU will listen politely and decline to take the recommended action. Jim http://www.foxnews.com/scitech/2011/07/07/scientists-fight-effort-to-redefin e-time/?test=faces -- James R. Frysinger 632 Stony Point Mountain Road Doyle , TN 38559-3030 (C) 931.212.0267 (H) 931.657.3107 (F) 931.657.3108
