Slashdot Mirror
'Leap Seconds' May Be Eliminated From UTC
angry tapir writes "Sparking a fresh round of debate over an ongoing issue in time-keeping circles, the International Telecommunications Union is considering eliminating leap seconds from the time scale used by most computer systems, Coordinated Universal Time (UTC). Since their introduction in 1971, leap seconds have proved problematic for at least a few software programs. The leap second added on to the end of 2008, for instance, caused Oracle cluster software to reboot unexpectedly in some cases."
Now waaaaaait just one second! Oh, scratch that...
Yeah, leap seconds suck, but the proposed solution (to let UTC drift farther and farther away from reality) sucks even harder. UTC should just be abolished in favor of UT1. Computer clocks are so crude anyway (mine is off by 3 seconds right now) that the supposed benefits of UTC's constant second are really non-existent, every computer needs to have its time adjusted now and then no matter what.
Isn't the problem with Oracle here? It should not be that difficult to fix their software. What's the difference with Summer time change?
The proper solution is to make programmers aware of leap seconds. There are 86400 seconds in a normal day, however there is an additional second added once or twice a year to adjust for solar time.
Wikipedia documents it quite well and programmers in modern times should be heading to wikipedia almost constantly anyway. The real problem occurs when the date/time is given in seconds since an "event" such as Jan 1, 1970. Most programmers don't know about leap seconds and I must admit, I don't generally bother calculating for them. But if it were necessary, it would be relatively trivial to do so.
We shouldn't remove fixes to the clock just because programmers are undereducated. I'm quite convinced that just posting this on Slashdot will raise awareness across a high percentage of the programming world.
I also always wondered why undergraduate studies for computer science didn't make time a relevant issue. It seems as if it's one of the more complex topics and yet, we don't pay any attention to it. Last formal education I had on time (not talking about physic related, but calendar) was in primary school. There are so many time systems out there that we should pay more attention to educating programmers on it.
Perhaps Oracle should concentrate more on making their software reliable, and less on lawsuits.
From what I recall Digital VMS didn't have that problem, and even had no problems migrating an always on system over different processors, and keeping the cluster running over more than 15 years. One second and Oracle crashes.
It's a pity which of those companies survived.
The issue is the faulty time implementation in software, not time itself.
They aren't predictable in advance. They are basically the noise in the solar system's timekeeping. It's impossible to write code that knows in advance when they will occur, since they are only announced six months ahead of time. So any clock that wants to stay in sync with UTC must be connected to either NTP or GPS or similar timekeeping service.
If only those darn astronomers didn't care so much about keeping the sun at Greenwich precisely at the meridian at high noon, we wouldn't have this problem.
The determined Real Programmer can write Fortran programs in any language.
I guess for some train timetable the question of using UT or UTC will be quite interesting in 20 years (when the difference is 15 seconds). Abandoning the leaps seconds for a millenium seems a way to make the issue hide from our sight, but then we need to abandon using anything non-UTC-based for timetables.
And imagine "the problem of leap hour" - Y2K will pale...
OMG !
please twist reality so that software developper won't make errors ? THAT's the idea ?
Considering people I work with are still today unable to get the proper week number in a given year in their applications, I understand the leap second can be a hassle, yet it does exist for a reason.
Who remembers that 1900 and 2100 weren't and won't be bissextile ?
Rules exist and govern the world. When implementing them, first thing is to get to know them.
Leap seconds are handled well, when the system supports it well and the software is not utter crap.
I am always annoyed when people break basic things to make software work (e.g. hardware, also see ACPI). Now they are not only breaking hardware, but redefining measurements to make buggy software work. What comes next?
I can understand when something is changed for convenience purposes (to have simpler calculations), but justified with buggy software is plain wrong. And I surely don't care if an Oracle database "reboots"... whatever that might mean.
I, for one, like the idea of being able to take a the UNIX time of event one and subtract the UNIX time of event two to get the elapsed time. Keep it simple. But it won't be simple because making the change now still means pre-2010 will be handled differently, so I'm not sure this is a good idea.
This is a good move but really the whole time system is messed up. Our current system has timezones which extends a flat-earth mentality and pretends like the world has 24 sides (except in Canada where they have 30 minute timezones). Your location should have nothing to do with time, it's absurd that we still have timezones.
China had the right idea -- no timezones in that country.
It's all well and good to blame developers, but what about when the definition of time itself we have to work with frequently doesn't account for them (i.e. Unix time).
http://en.wikipedia.org/wiki/Unix_time
While we are at it, why don't we get rid of leap year correction at all? Why do we still have leap year correction? I mean, 1 day every 4 years means a month every 120 years means a season shift every 360 years. People won't notice it during their 'normal' lifespan (apart from cryonics). What benefits does the leap year correction itself bring? What unforeseen consequences will occur when the leap year correction isn't applied anymore? Why is it important to have a perfect "seasonal year"/"seasonal calendar"?
Quisque verborum suorum optimus interpres...
The original article has a quote from one person who sees through the mess to the root of the problem:
Simply resolve the "underlying geophysical issue" and the problem will be solved.
I'm sick and tired of these hip, "ironic" sigs. This is an actual, honest-to-goodness no-nonsense sig!
Isn't this like legislating that PI is 3.14 because some people have problems with the idea of irrational numbers? If programs have issues with leap seconds, it sounds like programs weren't written properly, not that the spec needs to be rewritten to accommodate this flaw. Would these same people have demanded that it be 1999 again to avoid all the costs of the Y2K fixes?
"The leap second added on to the end of 2008, for instance, caused Oracle cluster software to reboot unexpectedly in some cases."
And people wonder why I tell them to avoid Oracle at all costs.
They don't have the team to debug-test this crap, they *ONLY* test for running functionality.
I got hit by this bug - it cost me half a million dollars.
If you use Oracle software, you're a total fool.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
Sounds to me like some programmers are putting the blame on anyone else than themselves ... I'm wondering, how do computer systems cope with re-syncing the local clock with a remote time source, e.g. NTP server? Computer RTCs are _never_ exact, so updating the local time is necessary in regular intervals, which will always lead to time jumps of milli-, micro- or even complete seconds and more. If your software can't cope with that, fix your software, but don't expect the universe will adapt to fix your shortcomings!
The historical record of time_t is already ambiguous and cannot be corrected by abandoning leap seconds. There is a way to get leap seconds out of the kernel and into user space which amounts to reclassifying them as decrees of change of civil time and putting them into zoneinfo while letting the broadcast time scale not have leaps. It's a matter for posterity whether the word "day" will be re-defined by the ITU-R, changed from the current treaty-specified "mean solar day" to a technically-defined "atomic day".
The last thing we want is every programmer inventing his or her own way to deal with this - imagine the mess of mutually incompatible implementations. Moreover, just how do you propose to change time-validation code to accept 23:59:60? With leap-days, it is quite clear when February 29th is acceptable and when not (and look how many people still get it wrong!). With leap-seconds, there are no rules. Just imagine the myriad of ways creative people will be able to foul this up! Leap seconds should be completely ignorable for everyone outside of physics and astronomy. They should disappear into routine time-corrections from the central time servers.
Enjoy life! This is not a dress rehearsal.
That is utc with choice of correction factors. Never more than 10ns correction but at unpredictable times, a few 100s of ns every week at midnight (old UTC) on Sunday or an occasional annual update of a few seconds. Pick the update scheme that suits your situation best. They could be called UTCa, UTCb etc. To most people that don't care, it will all still be UTC.
Nullius in verba
``Since their introduction in 1971, leap seconds have proved problematic for at least a few software programs. The leap second added on to the end of 2008, for instance, caused Oracle cluster software to reboot unexpectedly in some cases.''
That just means that the software contains invalid assumptions. And, in this case, it seems to me that it was quite poorly worked out. Time being off by a second causes the system to reboot? I don't think that's what the customers ordered.
Please correct me if I got my facts wrong.
Getting rid of leap seconds in the representation would be a mistake in the long run. A much superior fix would be to have computers keep track of TAI internally and then convert to UTC with a leap second table, much the same way we convert to local time with a time zone table.
Cluster software should be running off of a leap second free distributed clock, and TAI or the equivalent is the best one we have, handily provided (within a constant) on a world wide basis courtesy of the GPS system.
POSIX time_t values as it stands today isn't much of a clock at all, more like a short hand for encoding a wall time. We should have a new interface for a reference clock that doesn't need unpredictable adjustments every couple of years, _by definition_.
I doubt most of us would miss Mondays.
I think it makes absolutely no sense for most computers or programmers to have to account for leap seconds.
The reality is that computers already have to allow for their clock drifting from universal time, that's why we have NTP. There's no point getting individual computers account for leap seconds, it would be easier and less error prone if reference clocks transparently accomodate leap seconds (ie without sending a 23:59:60 to the world) and everyone else can just drift back in sync with them when one occurs.
There may be a few applications where a computer really does need to accomodate leap seconds (such as a reference clock!) but for the rest of us the additional complexity gives no advantage whatsoever.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
They ought to have abandoned leap seconds in the year 2000, which would have made a dandy new epoch, and simplified all date calculations for a millennium or so. There is absolutely no reason to inflict leap seconds on civil time; the amount I'm off from the center of my current time zone already introduces more error than that. It's just not important to anyone but astronomers or masochists. Well, and maybe sadists (especially standards wonks).
Comment removed based on user account deletion
Since 1971, 24 leap seconds have been added on to UTC in order to reconcile UTC and Universal Time.
In the revised ITU plan, the divergence between UTC and UT will be allowed to grow over the next few hundred years, and could be reconciled by a single leap hour at some point.
Hmmm... let's say: 40 years for 24 leap seconds... yeah... it would be allowed to grow over the next 60 hundreds years... quite a few indeed (some would even argue that's the age of the world).
Questions raise, answers kill. Raise questions to stay alive.
Can someone explain what kind of business the Oracle cluster was doing with the seconds?!
This is exactly what should be done. Since Unix time does not include leap seconds, it is discontinuous--either skipping a second, or repeating the same one twice. Almost all software built on top of it simply wants a monotonically increasing clock, with no regard for the date. It is annoying to have to check for a leap second every second and in every application that needs this functionality. TAI is simply more appropriate for internal timekeeping.
Like leap years, leap seconds should only concerned when the time is needed in date form--after all, both of their goals are to keep our calendar and time of day in sync with solar time.
Let's face it, in we've found copies of the Epic of Gilgamesh dating to 4500B.C., the old testament (which is really more a monotheistic superset of gilgamesh) is from 1800B.C.ish. The real reason only "scholars" got the whole math thing is because they were the only ones who knew why the were counting down instead of up.
We're all supposed to set our clocks wrong because Oracle can't write software that doesn't crash? I think not.
Probably just another attempt by Larry Ellison to demonstrate his power; one really wonders what he is trying to compensate for.
I've worked with NTP for nearly 20 years now, and the leap second adjustments isn't a real problem.
The crux of the matter is that we've insisted (in both Unix and Windows) on measuring calendar events in seconds:
The proper solution is to use Julian Day Number as the basic unit for calendars and (SI) seconds for any kind of short-term measurement. If you really need second/sub-second precision for long-term (multi-day) measurements, then you have to accept that the conversion is not just a matter of multiplying/dividing by 86400.
Calendar appointments and similar things should be defined by day number and some form of fractional day, not SI seconds.
NTP is somewhat to blame though: Even though it has full support for leap second handling (both adding and subtracting), the core of the protocol pretends that UTC seconds (without leap adjustments) is sufficient, i.e. NTP timestamps are defined to be in a 64-bit fixed-point format with 32 bits counting seconds since 1900-01-01 and 32 bit for the fractional seconds, i.e. sufficient to handle a 136-year block with a quarter of a ns resolution.
http://www.eecis.udel.edu/~mills/ntp/html/ntpd.html#leap
This causes small hiccups for an hour or so after each adjustment: The primary servers and those that either have a leap-second aware source or a cluefull operator keep in sync throughout the adjustment, while the remainder will slowly detect that their local clocks seems to be a full second off. Since this is way more than the default +/- 128 ms which NTP is willing to handle with gradual adjustments, NTPD will instead step the clock (backwards for an added leap second) and restart the protocol engine, after discarding all history.
Modern versions of NTP have been rewritten to use a vote between all otherwise good servers: If a majority claim that there will be a leap second at the end of the current day, then the local deamon will believe them, and thereby stay in sync even during the actual leap second itself.
Terje
"almost all programming can be viewed as an exercise in caching"
We have to make every clock in the world inaccurate because Oracle's software is crap...?
No sig today...
... now I'm going to have to rearrange my entire schedule.
Bastards.
-David
A bit tricky. Some haven't got the idea of leap years yet.
The title of this article should be "lazy incompetent programmers WIN AGAIN!" Sheesh.
Every day is a slightly different length due to tides, etc. Even strong winds can shave off (or add) a microsecond or two.
The BBC did a documentary on it.
No sig today...
Of course there's a Prius in the picture in TFA. I mean sure, it's gonna suck power like nothing around it (poor students must have enought light to avoid eye strain, bla bla bla) but look .. a Prius.
mov ax,4c00h
int 21h
They should have introduced 'look' seconds before they introduced 'leap' seconds. Would have saved a lot of trouble.
Never understood why time has to be so complicated.
If I was king, here's how's my vastly simplified implementation would work
1. There is UTC time.
2. That's it.
No time zones, no daylight savings, nothing. Only UTC.
So when it's 12:00, it's 12:00 everywhere. So midday for me would change from 12:00 to 22:00, and for someone in New York midday would be 7:00. It's just a number, deal with it. Everyone in my timezone would quickly associate lunchtime with 22:00, and so on, and from that point there would never ever be any time zone/DST issues ever again. Whenever you have to adjust something, you adjust your life, not the clock. If your local area wants a form of DST, they simply tell everyone to rock up to work and hour early and go home an hour early. Clocks are becoming so critical these days, that it is now easier to change our behaviour than the clock.
Maybe I've oversimplified it, but everyone I've told this about so far likes the idea.
Where is the problem here? Just because Oracle programmers don't know how to handle time there is no need to abandon the leap second. What is needed are better programmers that have better education and actually know how to program.
The ITU cannot fix this problem. In charge is the "International Committee for Weights and Measures" http://en.wikipedia.org/wiki/International_Committee_for_Weights_and_Measures which is older than the ITU. The software should reflect the time defined by the committee. The whole discussion is ridiculous, you only need a table with the number of leap seconds defined and a function fixing the 24 exceptions to the unleaped time http://en.wikipedia.org/wiki/Leap_second
If we would not have fixed it, the deviation would sum up to nearly half a minute. How want you fix that? In an effort similar to the Y2K bug problem. Painful nonsense.
If a database crashes you should fix the code starting with the underlying operating system and programming languages. By the way the definition of Time in most languages should be corrected, because f.e. http://download.oracle.com/javase/1.4.2/docs/api/java/sql/Time.html#Time(int, int, int) It is wrong that a minute can have only 60 seconds. It could also have 59 (not yet happened) or 61 seconds. If the ITU makes the change, time in GPS announced and real time will deviate. This is nonsense.
The solution is to keep time with TAI, which is guaranteed to increase by 1s every second, and DISPLAY time in UTC with a TZ on top if you wish. Doing calculations on UTC is bound to result in bugs, people should just forget about it. And also forget about hacking NTP's drift and other mechanisms to accommodate for leap seconds, that's not what they're for. It's just going to add more complexity and reduce precision. It's such an ugly hack I'm shocked that you should seriously advance it.
TAI is simple. It's the number of seconds since a reference date. No days, leap seconds, whatever -- just counting seconds. Want to display local time or UTC? Add the leap seconds and the TZ, and you're set. Want to do a calculation? You can substract TAI values to get nice, friendly seconds without fear of someone pulling the rug from under you.
Seriously, it's not complicated.
Accounting for leap seconds is complicated and error prone. It's also completely useless; the solution exists and it's called TAI.
Example: how do you figure how long an operation has taken? With TAI: := tai() := tai() - starttime
starttime
dosomething()
duration
That's it. How do you do that with leap seconds sneaking on you? It's impossible to do, at least reliably.
Does anyone else find the expression "software programs" grating?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
There's a reason why the second is defined based on an atomic phenomenon. An earth day is something hilariously unreliable; it varies all the time. A near earth asteroid would measurably alter it. Today we can measure time with accuracies in the 10^-15 or something, possibly even less. And besides, you're confusing the problem of defining the base unit (second) with choosing its scale and keeping a calendar. The SI second was scaled to look like the standard second used for centuries, just defined more precisely. The problem here is that the "real" second in the historical definition (one nth of a day) varies because of astronomical phenomenons that cannot be predicted (unless you can solve the n body problem for n very large and have inventoried the whole solar system), it's not a time keeping problem.
There's a solution to all this, it's called TAI. There is no reason not to use it but ignorance and incompetence. Every other "solution" that has been advanced here was completely, utterly stupid.
Clocks should strive to give the most accurate measurement, not lie to their users.
The solution exists, it's TAI. You use TAI internally and convert to UTC (or your TZ) when displaying, similar to unix time.
Non-idiot programmers have these awesome computing devices with operating systems and tons of ram and hard drive. Sadly, many of us idiot programmers work on devices that have just enough code to run the initial system check and then if you want something you need to compile it and do it yourself.
Of course, we could use libraries, but the boss doesn't want to buy a library for each thing and the open source library has a GPL license or a "not for use in commercial software" or whatever license. Or there's a "just give me credit in the program somewhere" license... umm there's no UI... where can I do that? Engrave it on the cover?
Or we could just open source everything we do, then the first company in China that decides it would be easy to build now that the software is done can make it and sell it on dealextreme for 1/20th the price.
Nope, we write it over and over and over. We like feeding out families.
so no printf in embedded devices??? Do they have to write everything in assembler or just plain C with no libs (even libc)? No. They use libraries. These libraries have functions in them. These functions are often written by someone else.
They can do the same here.
Because 15 o clock could be midnight for all you know. Midday is rather important for humans who rely on sight to view the world around them.
Meeting up on the beach for a party at 10am is fine until you find out that this is three hours before the sun comes up...
Besides, since we already have GMT, would this not be indicative that we should use the UK Midday as the World Midday? But funnily enough, it's always USians who promote this idea and want it set to US continental midday.
Though the french too would have conniptions moving to "UK time". It's just they don't promote it as worldwide, just Europe wide (CET).
This draft standard smooths out Unix Time around the moment of a leap second:
http://www.cl.cam.ac.uk/~mgk25/time/utc-sls/
-paul
i gotta know what time it is, so fix your crappy software!
Politics is Treachery, Religion is Brainwashing
it's about time!
"Computer clocks are so crude anyway "
I've noticed this. My PC clock can't even keep time as accurately as my cheap digital watch. It can lose
20 seconds in a week. Why is this? Surely they use the same sort of quartz crystal mechanism?
This is one of many, many attempts to make the problem seem to go away, unfortunately enough their choice of 1000 seconds for the smoothing period is close to the worst possible: 1 second in 1000 is 1000 parts per million or 1000 ppm.
NTP has a maximum slewing rate of 500 ppm or half a second every 1000 seconds, so if your NTP upstream server was to start such an adjustment period, every single connected client would drop out of sync and be forced to do several steps each time the offset got above 128 ms. :-(
To make this work every single computer clock would need to be updated, while all the national radio standards, like the German 77,5 MHz transmitter, would have to disregard the new standard because the radio receivers would be unable to track it when it started the adjustment period.
Terje
"almost all programming can be viewed as an exercise in caching"
Well obviously the Oracle software worked properly and noticed that the customer had not payed their license to include the extra unlicensed second of operation.
Why are they not? Leap seconds should not be part of the time source, they should be in the display, just like when displaying local time from a UTC clock. Trying to smooth out leap seconds is of the utmost braindeadness.
Given your attitude, you've obviously never had to write code to manage dates and times. You'd think it'd be easy, but it's by far one of the most difficult and error-prone software development tasks around.
You do realize that Oracle was listed just as an example, right? It was probably only selected to get a rise out of people like yourself, who've gone all anti-Oracle after their purchase of Sun.
If Oracle, who employs many of the best developers who have ever lived, has trouble with this, then you can be sure that many other software developers and software vendors have created products that have similar issues, and then some.
not to use binary, because it's very hard for humans to read.
(I was talking about using TAI in a program, not for human communication)
The solution, as the parent says, is to continue publishing leap second announcements but to start distributing TAI. Those who feel a need to track UTC can then insert the leap seconds themselves while other can track TAI and provide lookup tables for conversion to UTC or local time for display just as we do now for DST an local time zones.
And no, this does not mean putting the correction off for some future generation to deal with. It means realizing that there is no need for a correction at all and that Earth rotation based time is merely a local convention to be handled by an appropriate lookup table.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Time (and TAI) is independent of time zones. Time zones are a way of displaying time. Just like 10 in base 8 mean 8 in base 10, but represent the same number.
And TAI does not have to be calculated, except in as much as it's transmitted indirectly in NTP (which transports UTC and the difference with TAI), because that's where all official time references are derived from.
So because the software isn't being designed to handle the leap second we should get rid of it? Kind of like in Windows how when there's enough bugs we just ignore them an make a service pack to buy us time for the next inrush of bugs.
why don't they drop the silly daylight saving time thing.
Its been proved that nowdays it doesn't save any electricity, and just messes up peoples schedules and biological clocks.
In the latest issue of SciAm its listed and one of the inventions humanity would be better off without. (along with the space shuttle)
Can someone explain why we don't just wait until it adds up to a whole day before adding the 'leap'? We're set up to deal with leap years as it is, would it not be less hassle to deal with similar adjustments (albeit less frequent or regular) than dropping extra seconds in more often?
Python coder | PyQt Applications | Writer
But very often if you -were- using UTC already, then it was for a timekeeping/logging process that at least -may- involve us lowly humans.
So let's say you switch to TAI for all internal record-keeping. Great. Now a human needs to know what human time was associated with the TAI record. No problem, you say, just unleash the formula and look up tables and pass that to the display routine. The display routine looks at 23:59:60 and goes *BOOM* just the same as it did with the UTC codes.
I do think the -programs- need to be fixed, rather than the leap seconds dropped (although I don't see any serious problem with that either.. leap second-aware apps would simply see no further leap second insertions, and it wouldn't be an actual issue until many centuries later).. but saying that the programmer should switch to TAI is oversimplifying things.
I do think the -programs- need to be fixed, rather than the leap seconds dropped (although I don't see any serious problem with that either.. leap second-aware apps would simply see no further leap second insertions, and it wouldn't be an actual issue until many centuries later).. but saying that the programmer should switch to TAI is oversimplifying things.
How would you implement time(1) taking leap seconds into account? Contrast with tai:
starttime := tai() := tai() - starttime
dosomething()
duration
For those of you wondering WTF this is all about, Wikipedia has a good write-up on leap seconds: http://en.wikipedia.org/wiki/Leap_second
In the course of every project, it will become necessary to shoot the scientists and begin production.
No, actually, it won't. Read this: http://queue.acm.org/detail.cfm?id=1773943
The problem is that it would introduce variable seconds, which would cause much worse problems.
One example is electric power systems. The frequency in the AC power system is what determines how much power should be generated, if the frequency is above or below 60 Hz (or 50 Hz) then each power station should decrease or increase their generation by some amount proportional to the frequency difference.
The accumulated difference in total cycles over a period is used to calculate what was the difference between total energy needed and generated on that period. With leap seconds all you need to do is to divide total cycles by total seconds to get average frequency. With slow adjustment this would be much more difficult.
It is the duty of those of us who have brains in our skulls to ensure that everyone else has a vernal equinox tropical year calendar that is as accurate as possible.
This has to be one of the most obscene examples of attempting to alter reality to fit bad programming.
(It's never too late to join the Renaissance)
Different applications have different needs as far as time goes, which is why we have so many different time standards (UTC, UT0, UT1, TAI, GPS, etc). Eliminating the leap second from UTC would simply make it redundant with TAI, and would leave us lacking a standard that has the desired properties that UTC was designed with. Furthermore changing UTC at this point wouldn't simplify anything as as programmers would still need to account for leap seconds that have already occurred. If you want a global time base that is simply seconds since an offset, use TAI, since that is what it was designed for and stop fucking with UTC.
Although there are pages and pages of information there, nothing in the article in any way shows that multiple time sources actually cause real issues with the current NTP implementation.
The only mention of it is a thought experiment:
Imagine a server-selection algorithm that is moving around among candidate servers of similar quality. The result is constant jumping—a classic case of asymmetry jitter. Such jitter is not hard to observe in ntpd, where a connection to multiple peers is in fact recommended.
If "such jitter is not hard to observe in ntpd", where are the observations? They may exist, but if they aren't in this paper or in another paper referenced by it, that's not good science.
I'm in Saskatchewan, Canada. We don't do DST...clocks stay the same year round. It's great, except that I telework to a place where they do use DST, so I have to adjust all my work calendar appointments twice a year.
count you in Soviet Russia!
Support SETI@home
As if the endless stream of Oracle security vulnerabilities were not bad enough we have "unbreakable" high availability software that crashes when it encounters a leap second.
I don't know why its soo difficult for people to understand you ALWAYS use time functions to calculate time. After multiple discussions on this topic I still see people internally doing math with seconds and printing the results as if Time + 86400 adds extra day or Time + 3600 an extra hour or Time + 60 an extra minute.
It makes me sad because I know our lazy QA dept would never catch it until it goes into production and fucks up a customers system.
Changing leap seconds to appease morons who shouldn't be writing software in the first place seems to me to be a particularly stupid thing to do.
Do we actually care about that level of accuracy?
So, just because you don't think it is important, it shouldn't be bothered with? There are plenty of apps that are probably sensitive to having proper time keeping. Take GPS systems for example. Losing a few seconds could have a profound effect on all the devices that use data transmitted by the the satellites. Just because some Oracle idiots can't write a system that consumes UTC time correctly is no reason to hobble the rest of the world.
HA! I just wasted some of your bandwidth with a frivolous sig!
Proper solutions is to count seconds only and deal with "leap seconds" and other horseshit in the translation layer. Then you can have a map of all the corrections that are needed to the second calculation. Simple.
A second is the only 100% defined interval of time. "day" is not defined in terms of seconds hence it can only be approximated. "day" also changes from one to another thanks to external factors on our planet.
If the day is lengthening on average .0017 seconds every century, that averages out to 46 nanos more every day. That is hidden under larger microsecond fluctuations caused by weather and earthquakes. Five nanos is 50 million more arithmetic operations on the fastest supercomputer - more than I'll do by hand my entire life.
TAI (number of seconds since the TAI epoch) would be converted to UTC by simply adding the appropriate number of seconds. UTC is a discontinuous scale consisting of segments of atomic time seperated by leap seconds. "23:59:60" is the conventional way of displaying those discontinuities. You can't get away from them as long as you insist on displaying UTC-based local time, but you can at least move them to the display routines that already have to deal with DST and time zones and get them to hell out of the fundamental timekeeping software.
I don't see that applications should ever need to be aware of leap-seconds.
There is no need for it ever to be an issue.
The whole issue should be transparent to the application programmer.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
So the choices are 1) do leap seconds, which cost money to implement, introduce safety problems into various mission critical systems (which cost money to wring out), and have... no benefit whatsoever.
Or 2) don't bother with leap seconds. Then you won't have to do the work of introducing them, you won't have to code around them, you won't have to check the code you wrote to get around them, etc, etc... and there's no noticeable downside whatsover.
The choice seems pretty obvious to me.
Option A is to introduce a totally unnecessary leap second into our time system, then force everyone to code around that and check all that code. Option B is to just not do it. Doing away with leap seconds saves money and effort, and there's literally no downside.
The drift rate is so slow that everyone currently living will be long dead by the time this becomes noticeable, and if it's a problem far in the future, they can introduce a leap minute.
and
This is, quite frankly, nuts. We're taking a perfectly good, regular time system, deliberately introducing random error into it, and then forcing programmers to be able to realize this, code around it, and test the workarounds. All this costs money.
Or we could, you know, just stop doing that. UTC and solar time drift apart so slowly (a couple of seconds per decade) that it would be many, many years before the difference was bigger than the margin of error of the average timepiece, and probably hundreds of years before it became noticeable to actual humans. If it becomes a problem then, they can just add a leap minute. But deliberately screwing up your time system, and then forcing system designers to work around that? Dude, that's not a feature.
Getting rid of leap seconds would mean Letterman couldn't repeat this joke (paraphrased since I don't remember the exact wording):
Scientists have added a leap second to the year, which is just enough time for Stephen King to churn out another book.
(I repeat that joke as a Stephen King fan, btw. The first time I heard the joke was likely in the late 1980s or early 1990s, when SK was more prolific.)
And the proposal is that it stop being an astronomical timescale. So?
The thing is that regardless of what UTC and TAI were MEANT to be for, in practice, people are using UTC as if it were TAI. And it's probably easier to change UTC than revise the entire Internet.
The situation here is that we have a perfectly good time system that slowly gets out of sync with the rotation of the earth, because the rotation of the earth isn't constant. So we've legislated that the time system must be "fixed" because people have problems with the idea of this getting out of sync. That wouldn't be too bad in itself, but it 1) costs money to introduce the leap second (you have to figure out when to do it, make announcements, adjust your time sources, etc), 2) it costs more money to code around the change you introduced for no particular reason, and 3) it costs still more money to test all your changes. And you avoid... an unnoticeable change in your perception of time. It's crazy.
We're deliberately introducing errors into the time signal to avoid an unnoticeable difference between UTC and solar time, then forcing programmers to spend time and money coding around this. Why not just stop?
Life is hard. Go eat dog cunt and set yourself on fire.
Boy, you sure type tough. I bet you have tattoos and smoke and everything.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Oh, it's definitely no hassle as long as the correct measures are taken.
First, you need to make sure that you standardize the summer and winter hours across the whole nation, so that everybody switches over on the same date. It would be very confusing to have to call every business you deal with in order to ask whether they've already switched over to winter time.
Second, you should probably amend all local laws that specify specific times of the day so that they specify different times for summer and winter. You know, if my neighborhood bar opens at 8pm in summer and 7pm in winter, I would be pissed if a law that forces bars to close at 2am went unamended. I'd get one fewer bar hour in summer, and that's clearly unacceptable.
Third, in addition to amending all the laws, you have to make sure that you redo all the street signs that mention specific hours, so that that "free parking after 6pm" sign now lists separate summer and winter hours.
Fourth, whenever you schedule a late or early appointment in your calendar at a significant time ahead, make sure you take care to check whether the day you're scheduling it for is not past the switchover date, and you accidentally schedule the appointment for a non-laborable time for that season. Hey, we should probably redesign paper agendas so that the lines showing the working hours change for the seasons.
So you see, yes, it's definitely no hassle at all, as long as you take all of these measures, and any other ones that I may have forgotten.
Are you adequate?
The problem with this has been pointed out a gazillion times: updating the leap second table requires either connectivity or manual intervention, which are not available in all applications where people want to use UTC.
Are you adequate?
I'm in the "let the folks in 2310 add a leap minute if they want to" camp - but scrapping leap seconds now will have the inverse effect of breaking all the GOOD code now. A lesser evil?
They can still implement them as step functions, except implement them as dilations of existing seconds which computers already know how to compute. That is, instead of trying to modify EVERY piece of time-counting software to arbitrarily do something it was originally coded to throw an error on, just modify the primary layer so that the computer counts 2x clock cycles for 23:59:59 to increment to 00:00:00 instead of 1x clock cycles as usual. Every program running on that system would then keep correct time with the leap second added and without having to make a single modification to the software running on the system.