Slashdot Mirror
You Can Look Forward To 8 More Years of Leap Second Problems (cio.com)
itwbennett writes: As previously discussed here, the World Radiocommunication Conference (WRC) met "for nearly the entire month of November, and one of the hot-button issues [was] what to do about the leap second." But, as they did at the 2012 conference, the WRC voted to postpone the decision — not just until the next WRC in 2019, but until the one after, in 2023, while the International Telecommunication Union conducts further studies into the impact of tinkering with the definition of Coordinated Universal Time.
NTP handles leap seconds, where's the issue?
Have gnu, will travel.
Leap seconds are an artifact of our timekeeping system, and actual physical properties of our orbit.
For the ITU to be voting on if we keep leap seconds is kind of like politicians voting to determine that pi==3 ... it has nothing to do with reality.
Like it or not, you have to solve the problem. You simply can't get a bunch of tech people on a damned committee getting together and saying "we're no longer having leap seconds". That's just stupid.
Lost at C:>. Found at C.
The first proposal to abandon leap seconds was presented to the ITU-R in 2004, and subsequent versions have been rejected for over a decade. It is evident that the usual process of ITU-R decisions is not capable of coming to agreement on the subject of leap seconds. It remains to be seen whether they will produce a new framework for studies which can produce an agreement in 8 years.
Good. 8 more years of time working correctly. The fundamental issue is that the Earth just doesn't care what our atomic clocks measure. If programmers want an exact time system without leap seconds, use TAI, that's what it's for. Most people in the world don't care if it's hard to code leap seconds. Instead, most people go outside occasionally, and they expect that 'noon' means approximately 'sun at highest point'. We can switch to some system other than leap seconds, but if we expect 'noon' to have its conventional meaning, then we need to agree on a system that does that.
- David A. Wheeler (see my Secure Programming HOWTO)
Give or take a second.
Good. 8 more years of time working correctly. The fundamental issue is that the Earth just doesn't care what our atomic clocks measure. If programmers want an exact time system without leap seconds, use TAI, that's what it's for. Most people in the world don't care if it's hard to code leap seconds. Instead, most people go outside occasionally, and they expect that 'noon' means approximately 'sun at highest point'. We can switch to some system other than leap seconds, but if we expect 'noon' to have its conventional meaning, then we need to agree on a system that does that.
Except that system is NOT UTC. The system where "noon" means "sun at highest point" is called UT1. UTC is the "smoothed out" version of UT1 that allows an error up to a second.
Other than astronomers, nobody really cares about UT1. Nobody really cares about the 1-second error in UTC either when it comes to "noon." Heck, most countries shift where the sun is at noon twice each year to observe "daylight savings."
The question is whether there is any practical benefit to keeping UTC within 1 second of UT1. People who really need UT1 already use it. People who don't generally don't care about that sort of precision for when the sun hits its zenith.
SO -- what would happen if we just got rid of leap seconds for the moment and allowed UTC to drift for a while? We'd likely accumulate a few minutes of error over the next several centuries. Maybe when we get 10 minutes off, somebody might actually care that the sun isn't lining up, but that wouldn't happen for hundreds of years.
And, you might say -- "BUT, BUT... we can't let that happen, because what about our systems in the year 2500 which will be running legacy code and will suddenly need to insert leap MINUTES! DISASTER!"
No -- there would be disaster anyway. Because the earth is gradually slowing down, we'll begin to need more and more leap seconds as the centuries go by. By the time we get to the point that the collective error in UTC is enough for the average person to care where "noon" is, we'll already be to the point when two leap seconds per year probably won't be enough to keep us "on track," so we'll have to redesign the "leap second" system anyway as it's currently implemented.
Thus, there's absolutely no good reason for leap seconds (at least in the current system). If you really care where the sun is, use UT1. If not, by the time the collective error builds up enough for anyone to care, it will be time to overhaul the time system anyway.
Leap days (which we call leap years, because consistency is hard) are predictable. Software written 40 years ago will have the extra days at exactly the same times and with exactly the same frequency that the designers thought that they would. You never have problems where some parts of a distributed system got the update and others didn't. Either the code is working, or it's broken. It's also really easy to test.
Actually, I wonder how much software written 40 years ago correctly calculates leap years. Every year divisible by 4 is a leap year, except for those divisible by 100, except those divisible by 400. How much software will consider the year 2100 a leap year because the algorithm was dumbed down to every four years?
So just don't use UTC. The POSIX group only said "UTC" instead of "GMT" because they didn't know they difference and they thought saying "UTC" made them sound cooler. A lot of companies put it in their specs for the same reason. They're all like "Ooo we're all technical because we're using UTC!" Then you ask them if they're really using UTC or GMT and they ask you what the difference is. The only people it really matters for is NASA, and they convert from a well known time system to another well known time system as they need to. Most programmers just need to know the number of seconds since Midnight, Jan 1, 1970, GMT, as God intended.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Do you have any IDEA what a mess Daylight Savings Time makes of things like programs for process control and scheduling - and has at least since I did software for it back in the late '70s
Heck: For far longer than that. I hear the railroads handle it like this:
- In the spring, suddenly all the trains are an hour late. They work their way back to being on-time as they normally would - by running as fast as is practical.
- In the fall they STOP FOR AN HOUR. They just sit there with their engines running...
It's just easier than trying to figure out something "better" to do about it.
The claims that it saves energy are currently backward and getting more so. They may always have been, or it may be because lighting is more efficient (so the savings is small) while air conditioners are far more prevalent (and run more if people get home earlier).
Meanwhile it increases death rates: From DST-lagged drivers just after a change, from kids getting hit going to school in the dark on more days, from stress-related diseases exacerbated by the stress of the time change.
It also was a big factor in killing drive-in theatres.
If the government MUST twiddle with the clocks seasonally they should set them the OTHER WAY, creating Night Life Savings Time. We ALREADY have a shortage of dark time for evening recreation in the summer. Why take another hour away by shifting the clocks? Add one instead.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way