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?
Someone should calculate how many people are studying / debating this issue and how long they've spent on it, and then see how many leap seconds each person on the planet would need to experience to match the time spent.
They used the integrated face system to seamlessly add leap seconds to the calendar.
Have gnu, will travel.
Call it jitter and move the fuck on.
They could have written off a second, long ago and no one would care. We deal with leap years and biannually shifting clocks by an hour and that doesn't seem to be insurmountable.
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.
Call me strange but I find it hard to imagine that a computer clock being a second off for a moment is anything but invisible to your average software developer/IT worker/server farm.
I mean if your computer's clock is set up to sync with an NTP server every now and again, your system is probably already seeing corrections of that scale and more.
You Can Look Forward To 8 More Years of Leap Second Problems
I'm pleased to see others making this point, but personally I've never had any leap second problems, so I don't know who you're talking to, Mr Click-bait Headline.
systemd is Roko's Basilisk.
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.
Modern app appers use APP seconds or APP apps, not LUDDITE leap seconds!
Apps!
As I see it, this is a question about standardizing and implementing systems properly. Leap seconds are announced months in advance.
It can't be such a big problem systems that handle this correctly.
But then, daylight savings time still seems to give problems. Sheesh!
virve
PS. Anybody who knows about problems with leap days?
That sub-second syncronization is integral to the function of both GPS and the internet right? If we didn't account for relativistic variation in the timing of events between satellites and position on earth, GPS would completely non-functional. So yes, this is important. It simply isn't visible to the average user, even in IT. We don't need to deel with it because the low level programmers already have.
If your system's incapable of proper leap second handling and major changes are considered too costly? Then quit barking up the wrong tree and switch to TAI! UTC-based time is intended for humans, y'know.
Why is this such a big problem in the first place?
We already have leap years. We even have DST, which is different in every country and the rules constantly change. Yet we manage just fine (aside from it being personally annoying). Why are mere leap SECONDS such a big deal?
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.
Come on Slashdot! itwbennett is the new nervals lobster schill on /. All of his posts link to ITWorld or cio.com, both owned by the same company. At least disclose these ties. We know Dice is hurting for cash to pay their execs their $1 million salaries but this is just ridiculous. You are alienating and losing your most loyal users and soon there will be nothing left.
I just can't face the next eight years knowing that every now and then I will have to accept ANOTHER LEAP SECOND.
I...
I really can't...
Sorry, I'm trying to hold it all together, but the terrible knowledge of this continuing tragedy that ruins countless lives worldwide will continue is hard to keep...
No...
That's it....
I'm leaving.
GOODBYE CRUEL LEAP SECOND WORLD!
Rather than worrying about leap seconds all we really need to do is slightly alter the rotation of the earth to make it an exact 24 hour rotation. Problem solved.
"- news bulletin spending 30 seconds to announce a leap second, times the number of listeners"
Solution: stop pretending there's a problem and telling everyone what they don't notice and don't need to know
"- time spent by people discussing it"
Only happens because some whiner complains about it happening. Stop complaining. Solved.
"- time spent by developers coding workarounds"
Libraries already written to do it. Stop writing your own.Solved.
"- time spent by developers firefighting server crashes due to leap seconds"
See "time spent" above. Also if they'd ACTUALLY spent that time, surely they won't have it crashing. Solved by above.
"- customer time wasted because a system was unavailable due to a crash"
Given that it crashed because it was an incompetent programmer who
a) wrote their own
b) wrote it wrong
c) spent time debugging it and writing MORE code to get it STILL wrong
I think they'd be wasting time because the system was unavailable due to a crash when there isn't a leap second. Moot. Solved by above.
And the last three were all the same "count". Triple-dipping?
I agree. The problem is not UTC or leap seconds, it is that POSIX time ignores the existence of leap seconds. The more appropriate fix to me would be to redefine POSIX time as TAI. Or more accurately obsolete POSIX time so programmers are forced to choose between TAI and UTC. Who would ever have tried to convert from posix time to year/month/day/hour/minute without a library anyway?
But they only need accurate RELATIVE time. It does not matter if your HFT was done 7:32:12.244101 or whether it was done 7:32:13.244101. Leap seconds don't make a difference when you're looking for an interval, and THAT is what those advanced scientific calculations are looking for.
What DOES matter is lazy assholes making money from HFT who need their trade down in a form they "recognise", not as "seconds since epoch", which CAN be monotonic and unaffected by leap seconds; every second goes by and adds one to the "seconds since epoch" whether it is leap or not.
But that is "confusing" and they don't want it.
So, no, neither of your ideas are valid about leap seconds.
Leap days, but mostly DST, are getting YOU, the worker, to conform to the business practice of working 9-5 (plus unpaid overtime, of course). It ensures you get into the mindset of doing what the business tells you. A thousand workers all changing their clocks just so the company employing them doesn't have to change their opening hours sign on the front door.
However, each change of a leap second is businesses having to change their processes, if they constitute printing the date and time out and were written "in house". This makes business change at the behest of others. Worse, scientists, not MBAs. WORSE STILL, those dumb geeky moron "ASTRONOMERS". Hell, if it were the ASTROLOGERS doing this, they would at least get listened to. After all, US presidents have had Astrologer advisers. Not one AFAICT had an astronomer adviser.
So that's why.
DST: informs you you are a servant of the business.
Leap Days: no change to business practices.
Both fine.
Leap seconds: isn't driven by business demands.
TERRIBLE ATROCITY YOU HAVE TO SUFFER PROBLEMS FOR!
I own a sundial factory, you rotten bastard. What will my workers do if I fire them? The buggy whip manufacturers sure aren't hiring, not in this town.
And what about my kids, I put their college fund into developing ones with luminous dials.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
If programmers want an exact time system without leap seconds, use TAI, that's what it's for.
No, it is not intended for programmers (as a monotonic clock without daylight savings and leap seconds), or as an alternative to UTC. The TAI, International Atomic Time, is a time standard based on the coordination of approximately 400 atomic clocks from government labs around the world (50+ counties). It has never been intended to be a time standard for general usage.
Universal Time (UT) in its several variants (UT0, UT1, UT1R) are more likely to be appropriate, but UTC is still the best solution for being a time standard used as the basis for legal definition of time.
Just as programmers have been repeatedly chastised for making short sighted assumptions about only storing the final (two) digits of the year, as well as making errors about leap years by hand coding checks rather than using well tested libraries, using everyday approximations and assumptions (e.g. every minute is 60 seconds, or assuming a year is 365 days) causes serious problems in many areas of programming not just with time, dates and calendar.
The reason we adjust for leap seconds is that the speed of the earth's rotation 1) isn't exactly 360 degrees in 86400 SI seconds and 2) changes over time, so it's not even a fixed value close to 360 degrees in 86400 SI seconds.
The earth rotates approximately 360 degrees in one sidereal day. But since the earth is orbiting around the sun, it needs to rotate approximately 361 degrees per solar day. The leap second is not to account for this difference. The leap second accounts for variation in the mean solar day relative to the average mean solar day when the standard second was established.
What if it turned out that the worlds original Measurement System was actually the most practical?
The Megalithic System seems to be a built-in ratio system for the Earth, based on 366 degrees. It is almost intuitive. If Earth.exe=Sims.exe, the Megalithic Yard would be the Measurement System that was designed to be used within the .exe...maybe, as a metaphor?
Yet, it seems that when it comes to 'dividing time', the 366 degree system makes the most sense.
Thomas Jefferson, on his own accord, reproduced the Megalithic System, and attempted to make it the Measurement System of the US... under a different name, of course, since he was not familiar with the original system; he simply rediscovered it.
I am short on time, but feel free to do a few google searches about these concepts. There are a ton of great books and resources... and of course, mathematical breakdowns that show how it all works. The Jefferson-Megalithic story makes for good reading, for any nerd!
How do you know about the difference between UT1 and UTC, and not know that your hypothetical non-leap second corrected time standard has existed for more than forty years and is called TAI?
If the OS and / or applications can't handle a leap second, then it should be fixed. Nothing should ever be changed to make up for the shortcomings of bad code.
We need to switch to a better calendar.
13 Months
28 Days
1 New Years Day (Winter Solstice)
=======
365
Plus 1 Leap Day approximately every 4 years (Day After Winter Solstice)
The benefits?
-7 day weeks fit perfectly into 28 day months. Sunday would be the same day every month. So would holidays such as Thanksgiving, Independence Day, etc.
-No need to ever change the calendar.
-Paid twice per month, or every other week? Same difference.
-Is rent the same for February (28 days) as it is for March (31 days)? Not if every month is the same.
-Bye-Bye to "30 days has November..."
-Rename the months while we are at it. Screw the Caesars.
Bad. 8 more years of time not working correctly. The fundamental issue is that the atoms in the atomic clocks just doesn't care what the Earth measures. If non-programmers want to know when the sun is overhead, they can go outside and look at it.
There, fixed^H^H^H^H^Hbroke that for you. :)
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
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
What it IS is saying "Well, fuck those people in the future, THEY can do a much much bigger change and fuck things up royally (vastly more things would be problematic on a several-minute change that gets rolled out at a different time around the world than when it's a one-second change), just so long as *I* don't have to do anything".
Why the fuck is it fine to pass the buck 500 years? Here's an idea: we put in your "leap 5 minutes" sometime this year. That means for the next 1000 years, nobody else has to do the work to update all clocks in the world!
It's not the usual process of ITU decision that is the cause of the rejection. The cause is the fact that the proposition itself is stupid and make the problem even worst. To be certain that the programmers take seriously the fact that the duration of day is variable the adjustment code path must occur more often. The most effective way will be to define the civil time by a day counter and a offset since the start of that day. The day duration can be adjusted periodically. The programmed will know that the day is not 86400 second and the day increment code path will be tested every night.