You Can Look Forward To 8 More Years of Leap Second Problems (cio.com) 143
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.
How is it a problem? (Score:4, Insightful)
NTP handles leap seconds, where's the issue?
Re:How is it a problem? (Score:4, Interesting)
ntpd doesn't do that - when there's a leap second it counts backwards (or stops counting for a second, depending on how you think of it) in violation of the RFC, and then simply forgets about the leap second. It has the same fundamental flaw as POSIX.
Re: (Score:2)
NTP handles leap seconds, where's the issue?
There are a lot of "foo[60]" arrays out there, and leap seconds triggering things like writing beyond the end of an array, or overwriting the last entry, losing data for the previous second. And in many cases it goes unnoticed, which can be even worse.
Then there are interfacing between systems that handle leap seconds differently. Do you go from 23:59:59 to 23:59:60 or to a second 23:59:59? If the latter, what happens with jobs that are scheduled to run at 23:59:59.500?
In my opinion, the solution isn't t
Re: (Score:2)
NTP handles leap seconds, where's the issue?
There are a lot of "foo[60]" arrays out there, and leap seconds triggering things like writing beyond the end of an array, or overwriting the last entry, losing data for the previous second. And in many cases it goes unnoticed, which can be even worse.
Then there are interfacing between systems that handle leap seconds differently. Do you go from 23:59:59 to 23:59:60 or to a second 23:59:59? If the latter, what happens with jobs that are scheduled to run at 23:59:59.500?
In my opinion, the solution isn't to get rid of leap seconds, but for developers to not make assumptions. If you look at time.h, it states:
int tm_sec; /* Seconds. [0-60] (1 leap second) */
So why assume 0-59?
I may be mis-remembering, but it seems like a summer or 2 ago, there was a day with 2 leap seconds in it.
Re: (Score:2)
I may be mis-remembering, but it seems like a summer or 2 ago, there was a day with 2 leap seconds in it.
In 1972, there were two leap seconds, but one was in June and one in December, so there was no minute with more than 61 seconds. After that, there has always been 0 or 1 leap seconds per year.
Re:How is it a problem? (Score:4, Interesting)
I may be mis-remembering, but it seems like a summer or 2 ago, there was a day with 2 leap seconds in it.
Not possible. The leap second committee folks have a mandate never to let the difference between the UTC and UT1 (mean solar time) readings exceed 0.9 seconds. They usually decide to apply a leap second whenever the difference between UTC and UT1 approaches 0.6 seconds. Furthermore, they can add a leap second at the end of any month, although there is a preference for June and December and a second preference for March and September. For there to be two leap seconds in a day, something catastrophic would have had to have happened, like California sliding into the ocean, the Yosemite supervolcano blowing, or the Maple Leafs winning the Stanley Cup.
Re: (Score:2)
Re: (Score:3)
Heaven forbid developers actually test edge cases....
Another solution would be to use TAI if you really can't be bothered to deal with an occasional leap second. The whole point of UTC is to have a time standard that's based on TAI but is numerically close to UT.
I don't understand why this is suddenly a problem. Perhaps because of all the bootcamp developers writing code now?
Re: (Score:3)
Because, POSIX.
The committee which created POSIX (has any "design by committee" ever gotten things right?) decided to create an impossible situation - they both define a timescale of seconds in an epoch, AND define a day to be exclusively 86400 seconds. The only way that's possible is if a POSIX system doesn't claim to maintain UTC. Most/all do.
Here's a good explanation, with the gory details. [madore.org]
N.B. Leap seconds existed before POSIX, so they had the opportunity to get it right. They
Re: (Score:2)
Exactly, you got it right. What's depressing is that, even after decades, POSIX is still unfixed.
Re: (Score:2)
I'm not particularly coordinated, and I leapt at the wrong time. So now all my clocks are off and there is nothing I can do about it until next year. I've started training to do better.
Re: (Score:2)
A lot of industrial systems ignore daylight saving time. Too much hassle dealing with clocks jumping around when you are trying to log stuff or timestamp. Plus they keep changing the rules.
Leap seconds are even worse. They are unpredictable. You they cause your nice GPS time sync to UTC to be ever further off. Your code has to handle occasional 61 second long minutes.
For desktops no one much cares. For industrial/embedded systems it's a pain.
Re: (Score:2)
The industrial/embedded systems you describes must use TAI, not UTC or local time. Actually only the GPS broadcast the TAI in a direct usable form nearly everywhere. NTP broadcast UTC only and fail to send the TAI to UTC offset. PTP doe the right thing but is actually not broadcasted as NTP or GPS is.
Re: (Score:2)
You can still query an NTP server and set your timezone (if needed) to a fixed rather than a DST value. For instance, UTC-5 instead of "New York". No need to switch.
Re: (Score:2)
One of the issues if that if you need a high-resolution measurement of the real time that has passed between one event and another, it simply isn't available under POSIX systems. For scientific purposes, that sucks.
http://www.madore.org/~david/c... [madore.org]
Time lost (Score:1)
Re: (Score:2)
Daylight savings is a absolute mess compared to leap seconds. The dates when the shift occurs change often with as much notice as a leap second change. They vary per political boundary. Nothing is really coordinated. You can't actually compute how many seconds in the future a event will be. The direction changes per hemisphere. You get a hour (or two) of ambiguous time every year. Which 2:45am is it? You induce jet lag in large portions of the community.
Re: (Score:2)
Re: (Score:2)
Yet no one have found a better way to coordinate some important aspect of the worldwide telecommunication infrastructure. Keep in mind that there have to deal with governments with opposed sensibility or in conflict.
Someone needs to ... (Score:5, Funny)
Re: (Score:2)
...until they stopped.
Re: (Score:2)
They just need to stop when they're not in contact with the ground. By ... leaping into the air, or, ummm, diving into water.
Re: (Score:2)
Stop? What are you talking about? Are you unfamiliar with the Agile Development paradigm?
This is stupid ... (Score:4, Insightful)
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.
Re: (Score:1)
Re:This is stupid ... (Score:5, Interesting)
See, the problem is most people don't understand where our system of time keeping comes from or why it's important.
The reason we adjust for leap years and leap seconds is our calendar is a close approximation to our orbital period ... but it's not exact.
At noon, on the day of a solstice or an equinox, the sun is in a known position in the sky. We use it for important things like navigation and timekeeping, and knowing when the hell things like eclipses, sun flares, high tides, and comets might happen ... or that asteroid which might kill us.
It's a real physical property, which we kind of need to keep track of. It's NOT some thing you can say "oh, well, what does it matter if you're off by a couple of days?".
Re: (Score:3)
Re:gstoddart is stupid ... (Score:2)
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.
Re: (Score:2)
Really, if anyone needs this sort of precision, they shouldn't be using calendar dates and times, they should be using epoch seconds or milliseconds. Then you can map calendar artifacts to a particular second all you want.
Designate Jan 1 00:00 of each year as some specific second value and jitter to it. Or better, set certain dates of the year to less than a second and jitter to those.
Re: (Score:3)
What if the jitter routine has a bug in it? Is it then a jitter bug?
Re: (Score:2)
If we don't bother with leap seconds, then the distance that the sun will be off from being directly overhead at the equinox is about the same as it is now from being a couple of hundred miles away from the meridian. A simpler solution to the problem would be to, every couple of thousand years, have a one-hour reset.
Actually, the problem is worse than that (and shows the futility of the leap second system), because the earth is of course slowing down [wikipedia.org].
So, while we now have to add a leap second every few years or whatever, eventually that will become every year, then two every year, and then the current system will break, because right now we're only allowed two leap seconds per year by the current standard.
At best, adding up to two leap seconds per year will be able to keep up with the slowing earth for about anothe [ucolick.org]
Re: (Score:2)
The current leap second system is still enough for many centuries and even several thousand of years is the leap seconds are allowed every months or weeks.
Is you think about this more deeply you will realize that the best model will be to have what we actually call UTC defined in term of days counter since a epoch date and a second counter since the start of that day. This will allow to adjust periodically the day duration to the reality of the average earth rotation. Not only this model work with the earth
Re: (Score:2)
There are lots of things that depend on the position of the sun and stars to sub-second accuracy. Celestial navigation, pointing telescopes, pointing satellite dishes.
I don't buy the objections to using UTC. If you can't code a safety critical system for leap seconds, you probably shouldn't be coding safety critical systems. Note that it hasn't been a big problem for the last thirty years, why is it now?
If you REALLY can't deal with leap seconds, use TAI. That's why it exists.
Re: (Score:2)
If we don't bother with leap seconds, then the distance that the sun will be off from being directly overhead at the equinox is about the same as it is now from being a couple of hundred miles away from the meridian.
How is that an issue? How does this affect humans on the other side of the Universe that need to have a unit of time defined as a "day"? We should use a unit of time that is useful for humans yet is not tied down to what is happening on Earth.
Re: (Score:2)
Right, so then there's the question of why we give a fuck.
Re: (Score:2)
Yes this will make the programmer lazy about the problem and a big mess when the first change take reality. I largely prefer a model with a day counter and a time offset since the start of that day, so the day duration can be adjusted to the physical reality of the earth rotation. The advantage is that the programmer can test the day increment every night.
Re: (Score:2)
The reason we adjust for leap years and leap seconds is our calendar is a close approximation to our orbital period ... but it's not exact.
That's the reason we adjust for leap years. 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.
You are confusing sidereal and solar days (Score:1)
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.
Re:This is stupid ... (Score:5, Interesting)
We use it for important things like navigation and timekeeping, and knowing when the hell things like eclipses, sun flares, high tides, and comets might happen ... or that asteroid which might kill us.
I'm a professional astronomer, who occasionally needs to time things to sub-second precision over multiple years - and the leap second is, to me, nothing but a pain in the arse. Let's run down your list:
* "navigation" - No one navigates by the sun and stars any more - at least, certainly no one who needs sub-second precision.
* "timekeeping" - Atomic clocks keep time irrespective of the sun.
* "eclipses" - Eclipses don't care whether the sun's at the meridian or not: they only care about the relative position of the sun and the moon, which you can calculate perfectly easily with an arbitrary time standard.
* "sun flares" - Solar flares don't care whether the sun's at the meridian or not.
* "high tides" - The sun makes a small contribution to the tides (which are dominated by the moon), so the leap second *does* help you keep track of this contribution - but who the hell needs to know the high tide to the nearest second?
* "comets" - Comets don't care if the sun is at the meridian or not.
* "that asteroid which might kill us" - That asteroid doesn't care if the sun is at the meridian or not - but there *is* a chance that someone might miscalculate its orbit and not realise that it's going to kill us, because there was a bug in their code dealing with leap seconds.
So, this is something that genuinely puzzles me: who actually *wants* leap seconds? You seem to think that I should want them, but I certainly don't.
Re: (Score:2)
I'll agree with you on the rest of the list, but I personally have navigated using the stars, requiring to-the-second accuracy.
Re: (Score:1)
Would you expand on this? It sounded like a reasonable assumption to me. If you're saying there are situations where it's not reasonable, it'd be nice to know what those situations are.
Re: (Score:3)
Reducing a sight in modern celestial navigation usually involves calculating the expected altitude of a target celestial body at a particular time at a particular place on the surface, noting the actual altitude of the body, then using the difference to determine your distance from the reference location. To do that you need to use a time standard that stays in sync with the heavens, or correct for the drift in one that doesn't. UTC is convenient because it's accurate to about a tenth of a second, as clos
Re: (Score:2)
Why not just keep a separate clock for these purposes and let the rest of us be?
Re: (Score:2)
UTC IS the separate clock kept for those purposes. If you don't like leap seconds, set your clock to one of the half dozen time standards that don't have them.
Re: (Score:3)
At noon, on the day of a solstice or an equinox, the sun is in a known position in the sky. We use it for important things like navigation and timekeeping, and knowing when the hell things like eclipses, sun flares, high tides, and comets might happen ... or that asteroid which might kill us. It's a real physical property, which we kind of need to keep track of. It's NOT some thing you can say "oh, well, what does it matter if you're off by a couple of days?".
But we're not talking about days. There's been 26 leap seconds in 43 years, we're talking about a drift of roughly one minute per century. For most things being off by a minute or two wouldn't matter and if you know 12:01 = 12:00 a hundred years ago it might be easier to correct for that. While leap seconds keeps us in sync with reality, it means that if you want to do something every X seconds you can't just rely on UTC and NTP because at some point it'll actually go X+1 seconds. And leap seconds take worl
Re: (Score:2)
Reminds me of going to a conference at NIST with a bunch of engineers back when people had watches and didn't have cell phones. At some point everyone looked at the wall clock and thought, "OK that's what time it is... no wait, that's the actually what time it is. I'm going to set my watch." Lots of messing around with the wrist that day.
Re: (Score:2)
I had a friend once propose this without the additional day. I pointed out that the number of days in a year was odd and she gave up. I like your addition.
One issue: New Years is not a day of the week in your plan.
Re: (Score:2)
I think we need to switch to a day counter and a offset since the beginning of that day to match the physical reality of the earth rotation.
Re: (Score:2)
Re: (Score:3)
A second used to be 1/86,400 of a mean solar day (e.g. high noon to high noon). A slowing day would mean a lengthening second, which would screw up measurements of basic physical constants, e.g. the speed of light.
The current definition of a second is http://physics.nist.gov/cuu/Un... [nist.gov]
> The second is the duration of 9 192 631 770 periods of the
> radiation corresponding to the transition between the two
> hyperfine levels of the ground state of the cesium 133 atom.
In theory, any sufficiently advanced
Re: (Score:2)
If you're aiming a telescope, or a satellite dish, or computing an almanac, you care. The point of UTC is that it stays close to UT so that the people who need a time standard that's aligned with the actual rotation of the Earth have something to use. If you don't want to deal with leap seconds, there's already a standard for that. It's called International Atomic Time (TAI), and has been around since the early seventies.
Re: (Score:1)
No it isn't stupid. You may think it sounds stupid - but that is due to your ignorance. There are real considerations in determining whether to keep or end the addition/subtraction of leap seconds. Continuous time scales are fundamental to a number of navigation & economic operations.
Re: (Score:2)
That's OK, you're an AC and therefore I assume you're a moron.
You do understand that the navigation is ALSO intrinsically tied to the astronomical positioning of things, right?
That it causes problems for computers is a relatively modern problem. Keeping accurate track of the time as it relates to the actual sky has been with humans
Re: (Score:3)
You do understand that the navigation is ALSO intrinsically tied to the astronomical positioning of things, right?
Today? Mostly (for anything where accuracy matters to the degree that leap seconds will make a difference in under a few hundred years) it depends on the GPS position, or some equivalent. GPS time, unlike UTC, does not have leap seconds.
Re: (Score:1)
GPS time actually doesn't exist, because clocks in orbit differ from clocks on the ground, due to Relativity. There is no "GPS" time, and in fact, the differences in time keeping between clocks is integral to how GPS actually works.
Re: (Score:3)
Anyway, if you don't like that, you could use the TAI (International Atomic Clock Time) instead.
Leap seconds can be used for displaying time in UTC if you need to, while those that need a constant, uninterrupted tick of the clock could use TAI (or GPS) in the backend.
Re: (Score:3)
GPS satellites report a time that is a strict offset of TAI, which is the standard that is designed for use by people who don't want leap seconds. GPS positioning depends on the precise position of points on the surface of the Earth underneath the GPS constellation, so although the satellites report a TAI-locked time, to actually determine your position you have to do a correction that's very similar to UTC, except with a granularity that's more like leap nanoseconds instead of seconds.
Re: (Score:1)
like politicians voting to determine that pi==3 ... it has nothing to do with reality.
It's irrational to try to redefine the irrational as rational.
Re: (Score:3)
Re:This is stupid ... (Score:5, Informative)
Leap seconds are an artifact of our timekeeping system, and actual physical properties of our orbit.
The latter we are stuck with but the former is something humanity has the power to change. There are basically three choices.
1: Disconnect the civil time second from the SI second. Allow the civil time second to vary slightly to match the mean solar day.
2: Allow civil time to drift relative to solar time
3: Make periodic adjustments to civil time to keep it close to solar time.
Each choice hurts different people. Choice 1 hurts anyone who needs to convert between civil time and "atom time". Choice 2 hurts people who rely on civil time as a navigational aid and future historians. Choice 3 puts a rarely excersised special case into computer systems leading to systematic failures.
Re: (Score:2)
1) Will lead to many more confusion between the two type of seconds.
2) Will break the ancestral definition of time in all the civilization that ever existed.
3) The only way and nobody is seriously make any other proposition. The discussion is how to improve it because the leap second is rare enough to make too many programmers not taking it seriously enough and testing is enough.
So the solution is certainly not to make the adjustment more rare, but more often. My proposal is to define the civil time by a da
Re: (Score:3)
Re: (Score:1)
Re: (Score:2)
Example: on January 2200 we could just apply all leap seconds that are stale, around 10 or so.
The alternative, which is better is to do something so often that implementation problems get ironed out before the big-saved-up-event.
So instead of a leap second, have a leap milisecond inserted 10,000 times more often than the leap-10-seconds. Humans wouldn't notice and implementation errors would be seen and fixed quickly.
Has this actually affected anyone here? (Score:1)
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.
Re: (Score:2, Interesting)
It's never given me any problems.
Then again, I'm not the kind of person who writes my own date/time validation routines because daylight saving is part of Agenda 21 and fluoride causes autism. I suspect it's them making most of the noise.
Re: (Score:2)
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.
I would imagine that advanced scientific calculations as well as high-frequency-trading algorithms would be affected. Clearly the scientists can go fuck themselves, but I'm surprised that the needs of something as important as HFT has gone unheard in the WRC/ITC.
Re: (Score:2)
Why would a scientific calculation care about what time it is? Unless you're talking about astronomy, in which case astronomers have lots of time standards, and actually know how to use them.
Re: (Score:1)
Yes, leap seconds ruined my first marriage.
*I* can? Personally? (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
You can look forward to it. No-one said anything about looking back.
(black humour aside, I hope you get to do both!)
first proposed in 2004, not resolved before 2024 (Score:3)
Re: (Score:2)
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
How about fixing the systems? (Score:2)
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?
Re: (Score:2)
Leap seconds are announced months in advance
i.e. with less warning than the revalidation time for a lot of safety-critical systems.
Anybody who knows about problems with leap days?
Well, aside from the Zune infinite looping...
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 i
Re: (Score:3)
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?
Re: (Score:2)
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?
Actually, that rule is only true of the Gregorian calendar. Many countries have never officially adopted the Gregorian calendar, but rather use the Revised Julian Calendar [wikipedia.org], whose rules say that you only have leap years in centennial years when the year number/100 MOD 9 comes out to 2 or 6.
(This was done because the Revised Julian algorithm produces a much more accurate approximation to the true year than the Gregorian calendar.)
The Revised Julian Calendar and the Gregorian Calendar line up in their rul
Re: (Score:2)
Sorry to self-reply, but I should clarify that I believe most if not all Western countries have officially adopted the Gregorian calendar. But a number of countries with strong presence of Orthodox Christians have official churches which have instead adopted the Revised Julian. There have been some politicians in these countries which have claimed the official calendar is not Gregorian...
Obviously it's probably unlikely that anyone is going to care about this stuff 800 years from now. It's still an amu
Re: (Score:2)
Sorry to self-reply, but I should clarify that I believe most if not all Western countries have officially adopted the Gregorian calendar. But a number of countries with strong presence of Orthodox Christians have official churches which have instead adopted the Revised Julian. There have been some politicians in these countries which have claimed the official calendar is not Gregorian...
Obviously it's probably unlikely that anyone is going to care about this stuff 800 years from now. It's still an amusing bit of weird calendar discrepancies.
Re: (Score:2)
Leap seconds are announced months in advance
i.e. with less warning than the revalidation time for a lot of safety-critical systems.
Hmm., hopefully safety-critical systems are implemented so that they have provisions for leap seconds built in already. What should be needed is organizational procedures for setting the appropriate flag in time.
Further, I would expect that many safety-critical systems are more concerned with elapsed time from some epoch (switch on, last firing of engine, last heart-beat) and less about civic(?) calender time (we meet on January 2nd, 2016 11:01:14 EST).
Finally, in really hairy cases things should be referre
You are all aware (Score:1)
Re: (Score:2)
> That sub-second syncronization is integral to the function of both GPS
No. GPS does NOT use leap seconds.
what-if xkcd #26 [xkcd.com] is actually on-topic for once.
Re: (Score:1)
Re: (Score:2)
GPS satellites report time that does not include leap seconds. But your GPS receiver has to make corrections to that time that are much more accurate than leap seconds to give you the correct position on the Earth's surface.
Re: (Score:2)
GPS and PTP both broadcast TAI and UTC-TAI that sum up the past leap seconds, so your claim is not completely correct. I will add that GPS and PTP both lack a method to broadcast the leap second history table required to safely compute time in the past at the second precision. NTP need a major protocol upgrade to fix his multiples issues, or PTP need to be broadcasted as NTP is today.
Horses for courses (Score:1)
Good! 8 more years of time working correctly. (Score:3)
Re: (Score:3)
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 [wikipedia.org]. 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 UT
Re: (Score:2)
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?
Re: (Score:2)
Re: (Score:2)
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 [wikipedia.org], 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 [wikipedia.org] (UT) in its several variants (UT0, UT1, UT1R) are more likely to be appropriate, but UTC is still the best solution for being
Correction: 8 years minus 2.6 leap seconds (Score:3)
itwbennett the new /. schill (Score:2)
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.
We are looking at this the wrong way... (Score:1)
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.
This is an OS & application problem (Score:2)
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.
Don't Use UTC (Score:3, Interesting)
Re: (Score:3)
Are you sure YOU know the difference between UTC and GMT?
It's not that UTC sounds cooler... It's what we actually use. UTC ticks based on atomic clocks and it's what's distributed through NTP. GMT (really UT) tracks Earth's rotation, doesn't have a stable second, and there are no high-precision realtime references.
Most programmers just need to know the number of seconds since Midnight, Jan 1, 1970, GMT, as God intended.
time_t doesn't count the number of absolute SI seconds since the Epoch: it assumes days are always 86400.0 seconds long, and completely ignores leap seconds... even worse, before 1972 they used
Re: (Score:2)
I haven't checked but I suspect the situat
I wish they'd ditch daylight savings time. (Score:3)
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.