11 ms·
A positive leap second will be introduced at the end of June 2015
- billpg 12y agoRemember when we'd have one of these almost every year? Those were the days. Kids today... Get off my lawn.
- repsilat 12y agoThey really have dropped off since 1999: http://en.wikipedia.org/wiki/Leap_second#Insertion_of_leap_seconds http://en.wikipedia.org/wiki/Leap_second#Insertion_of_leap_s...
- deleted 12y ago[deleted]
- atonse 12y agoI'm curious to see how this affects Spanner (Google's new database that seems to rely on extremely precisely synchronized time to coordinate transactions). Anyone on the Spanner team able to comment?
- TheSwordsman 12y agoGoogle wrote a blog post about this a few years ago: - http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html http://googleblog.blogspot.com/2011/09/time-technology-and-l...
- bluelu 12y agoThere was a post in the past that google have their own custom timeservers for their servers, slowly adapting time over multiple days and months, so they are not affected by this.
- cordite 12y agoIn their databases that depend on time, they repeat that they use an external source of time. It seems like some of their designs are constrained around always non negative deltas between events, making things append only so their trees or hash tables are only balanced once when written to disk.
- Artemis2 12y agoI haven't read about Spanner, but wouldn't it be possible for their clock to measure time based on an epoch, instead of using the system based on physical factors (the rotation of the earth around its axis and around the sun) that we use?
- cordite 12y agoIt is probably easier in the long run if the servers had the same time as the machines that people use, which are regularly updated by their OS's choice of NTP server, since people run reports and react accordingly.
- vl 12y agoIt wouldn't affect Spanner or any other sanely implemented system - usually nowadays time is saved as "units from epoch", and leap seconds, days, etc. don't matter for internal calculations. It matters only for final conversion to printable format, debug logs, etc.
- rspeer 12y agoMost UNIX systems store time as "seconds from the epoch, according to UTC". The advantage is that you can always assume that 1 day = 86400 seconds. The disadvantage is that the time is affected by leap seconds. The same-numbered POSIX second can be repeated twice in a row. Spanner instead deals with it by changing the length of the second. If you're assuming time intervals are accurate to the second, or that times are monotonic, have you actually reconfigured your system to use TAI?
- tonyhb 12y agoThanks for the update. Writing a Go program now which is pretty sensitive to these, and it's pretty annoying to have to consider them in your tests.
- repsilat 12y agoThis leap second business seems like a pretty dreadful idea. Considering timezones are way off-base all around the world as it is[1], it seems a lot simpler to just let the clocks drift for a while. One less weird thing in our operating systems, much less opportunity for bugs in all kinds of code that deal with times. The set of people who really care about solar time "down to the second" is smaller than the set of people who'll be put out by 23:59:59 not being immediately followed by 00:00:00, and most of those people probably want sub-second accuracy anyway. Astronomers complaining about the clock time being wrong is exactly the same as farmers complaining about daylight savings. 1: http://poisson.phc.unipi.it/~maggiolo/index.php/2014/01/how-much-is-time-wrong-around-the-world/ http://poisson.phc.unipi.it/~maggiolo/index.php/2014/01/how-...
- VieElm 12y agoToo bad leap seconds will not be abolished before this happens, abolishing leap seconds is up for consideration in November 2015 at the World Radio Conference: https://en.wikipedia.org/wiki/Leap_second#Proposal_to_abolish_leap_seconds https://en.wikipedia.org/wiki/Leap_second#Proposal_to_abolis... I wish they had a call for public comments.
- johansch 12y ago"In May 2014, David Willetts, the ex-UK Minister State for Universities and Science,[38] described as a non-scientist with a degree from the London School of Economics and Political Science,[39] expressed opposition to the abolition of leap seconds. He indicated that as a layman, he wanted to keep "the link between time and people's everyday experience of day and night." He also wanted to keep Greenwich Mean Time in Britain, and "warned" that it would drift towards the United States.[40] An article in the Times science section suggested that the abolition of leap seconds would mean the demise of Britain's role in timekeeping.[41]" Just gah. UK: please realize you are a medium-sized EU country, not a global super power. :) Sincerely, the rest of Europe
- nullc 12y agoGah. The ignorance, it burns. It will take thousands of years for the drift to even amount to one hour. If people care about it then, ... they can switch timezones (e.g. like DST causes twice a year in most places) to compensate for it.
- micro-ram 12y agohttp://www.leapsecond.com/java/gpsclock.htm http://www.leapsecond.com/java/gpsclock.htm A cool realtime clock that shows the offset the GPS satellites work from, which do not include leap seconds.
- olympus 12y agoThis really messes with some of the stuff I do at work with test instrumentation since we use GPS time in the field but our computers use UTC. We had a problem late in 2014 when one of our instrumentation techs was using an old instruction manual and he was converted his data using a 14 second offset between GPS time and UTC, instead of the correct 16 seconds. Now we'll have to issue all new instruction manuals to the technicians-- or maybe we can just fall back to a 2011 version that had a 15 second offset.
- masklinn 12y ago> or maybe we can just fall back to a 2011 version that had a 15 second offset. Won't the new offset be 17s? The offset would only diminish if a negative leap second was enacted which has yet to happen.
- olympus 12y agoI must have misread the article. I thought a positive offset was different from all the other ones. In that case, it's still a new manual version, but much less unusual.
- nicky0 12y agoWrite in the instruction manual "The number of seconds offset is shown on the web page: <insert address of your updated page>"
- nullc 12y agoHurray, time to see NTP screw up hosts everyone on the internet yet again. (Oh wait, the last leapsecond event didn't even involve an actual leapsecond)
- adamtj 12y agoWhy don't we just switch from UTC to TAI and put the leap seconds in our localtime offsets? It makes all the problems go away, or else reduces them to problems we've already solved for handling daylight saving time. If you think about it, leap seconds are no different than daylight saving time. The only differences are that daylight saving time usually has 1-hour granularity and is occasionally redefined by your government, where leap seconds have 1-second granularity and are occasionally redefined by Mother Nature. We already know how to deal with repeating seconds and minutes (alternatively, with minutes or hours that are too long). Those happen during daylight saving time changes, but the ambiguity disappears when switching to UTC. We already record timestamps and communicate with UTC, applying a localtime offset for display or user input. That's a solved problem. Further, we know how to change the localtime offset. Most timezones do that twice a year. We also know how to handle timezone definition changes because ignorant legislatures sometimes modify when the daylight saving time switches occur. So, why don't we switch from UTC to TAI as an underlying time standard? When UTC leap seconds occur, we can treat them somewhat like a government redefining its timezones. US Eastern Time then changes from "TAI-05:00:35/TAI-04:00:35" to "TAI-05:00:36/TAI-04:00:36". If two UTC clocks are synchronized, then one accounts for a leap second and the other misses it, the clocks will no longer be synchronized. If they were TAI clocks, they would still be synchronized and both would still record and communicate correct timestamps. It's just that one would display localtime incorrectly. But, you would immediately know that was the case when you see that the offset is a second behind. Missing a leap second would be like having your computer is set to the wrong timezone, and would be just as easy to fix.
- themodelplumber 12y agoHow does the system-wide workload of changing from UTC to TAI compare to adding the leap second? No idea about this stuff myself, just curious.
- scott_karana 12y agoI think TAI is continuous, unlike UTC, so you can continue auto-incrementing timers without leap seconds and breakages, and just apply the leap-second to rendered time, not accounted time.
- uniformlyrandom 12y ago> Daniel Gambis > Head Daniel is clearly missing out on an opportunity to have the coolest title ever. 'Head of Earth Rotation', or 'Earth Rotation, Director of' would sure look nice on a business card.
- xg15 12y agoBeing able to address, in all seriousness, the "authorities responsible for the measurement and distribution of time" seems like a good second place to me though.
- joshschreuder 12y agoDaniel Gambis, Time Lord would go well on a business card.
- twic 12y agoThat is a cool title. But i'm not sure it's actually cooler than 'Planetary Protection Officer': http://planetaryprotection.nasa.gov/contacts http://planetaryprotection.nasa.gov/contacts Particularly given that her job genuinely is to protect the Earth from alien life. Well, and also to protect the rest of the universe from Earth life - which, predictably, is the more difficult bit.
- cperciva 12y agoThe Earth Orientation Center of which he is head belongs to the IERS which, until 2003, was the International Earth Rotation Service (it is now the International Earth Rotation and Reference Systems Service). So until 2003 there was, in fact, someone whose job title was "Head of International Earth Rotation Service".
- NelsonMinar 12y agoLast time we had a leap second in 2012, it crashed a whole lot of web servers. There was a bug in Linux kernel threading that MySQL and Java both triggered. Please forgive the self-link, but lots of details from the time on my blog: http://www.somebits.com/weblog/tech/bad/leap-second-2012.html http://www.somebits.com/weblog/tech/bad/leap-second-2012.htm... Leap seconds are a fact of timekeeping. Google's approach of slewing the clock seems like a robust way to implement it if you don't trust the operating system to do it right. http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html http://googleblog.blogspot.com/2011/09/time-technology-and-l...
- iwwr 12y ago>Last time we had a leap second in 2012, it crashed a whole lot of web servers. That exposed a bunch of underlying bugs, didn't it? It may be a good thing in the long run than without it, especially with a one year's head start.
- emptybits 12y agoSomewhere, there's a vindicated coder shouting, "See! I told you that extra code and storage to allow for a schedule of arbitrary future insertions of leap seconds would pay off!"
- NelsonMinar 12y agoThat's the optimistic view. But leap seconds also caused problems in 2008 and 2005. It seems more likely we'll just find some exciting new bugs. Hopefully not one that b0rks the whole kernel though.
- ck2 12y agoUgh not again http://phys.org/tags/leap+second/ http://phys.org/tags/leap+second/ Quantas crashed last time. I mean their computers, not the planes.
- caf 12y agoThere's no 'u' in Qantas - it was originally an initialism.
- yoha 12y agoIncidentally, time.nist.gov is down. It hosts a list of leap seconds at ftp://time.nist.gov/pub/leap-seconds.list.
- ars 12y agoIs there an NTP command to see if NTP was informed about the change?
- jzwinck 12y agoIt's not quite that simple, but I think this is a good explanation: http://support.ntp.org/bin/view/Support/ConfiguringNTP#Section_6.14 http://support.ntp.org/bin/view/Support/ConfiguringNTP#Secti.... (TL;DR: don't worry about it).
- quinndupont 12y agoThey did say that 2015 would be the year we got time travel. One second is a little less than anticipated though.
- gweinberg 12y agoIt could be worse. They could have leap tenths of seconds ten times as often.
- nullc 12y agoThat would arguably be better, the smaller distortion would be less likely to break things and the frequency would make it much more likely that things were tested against it. (Of course best would be to have none at all, and accept that several thousand years from now people-- if people still exist then-- may choose to slip the timezones by one hour to correct the drift.)
- jedberg 12y agoAt least this one is in June. Whenever they do one in December, you have to suffer through a terrible explanation of what a leap second is from a TV newscaster, explaining why the ball isn't going to drop for an extra second.
- nchelluri 12y agoDoes this require a code change?
- emptybits 12y agoYay, more sleep! Wait... (very briefly thinking about broken assumptions, date calculations, month-end assumptions, 0:59 versus 0:60 vs. 0:00, ...) dammit, I just lost more than I gained! Thanks, France!
- jgstultz 12y agoIf folks are (reasonably) feeling nervous about this, I've got a test program lets you insert leap seconds to test your application behavior. Would love to hear about anything folks see that might point to any remaining kernel issues. https://github.com/johnstultz-work/timetests/blob/master/leap-a-day.c https://github.com/johnstultz-work/timetests/blob/master/lea...
- mrgriscom 12y agoMy personal opinion is that leap seconds have no place in civil timekeeping. I love them as geeky trivia but in practical terms they are a disaster. They do solve a real problem of keeping solar time roughly in sync with atomic time due to the slowing rotation of the Earth, but in today's computer-dominated and interconnected world inflicting a one-second discontinuity every few years on millions of systems individually rather than handling it in a central place is a bad idea. It's like a mini-Y2K several times a decade. The core issue is we have two different needs: a hyper-accurate count of elapsed SI seconds, and a day-to-day date/time system that roughly tracks the position of the sun in the sky. UTC tries to combine these into the same thing, when they would best be left separate. For the former, we already have a pure atomic timescale -- TAI -- to handle this. I would go a step further and not even present TAI as a date and time, but rather a raw count of seconds like unix time. This is to enforce that TAI is not civil time, but rather a standard to benchmark and calibrate against. For the latter, I propose a new time standard that is a transformation function applied to TAI. The IERS, instead of decreeing leap seconds like they do now, would instead declare an offset and skew rate that smears the leap second out over a longer period. Something like: at date X, civil time will be Y seconds ahead of TAI, and will tick Z% faster/slower until further notice, where Z is expressed in a simple unit like parts-per-billion or milliseconds per day. Instead of leap seconds every 18 months or so, with this scheme the IERS could probably get away with making adjustments once every five years, and still stay within the 0.9s of true solar time as mandated by UTC. Any modern microprocessor could handle this transformation trivially. Most would not even need to as the internal clock resonators in 99.9% of the world's computers and clocks are less accurate than the skew rate Z. They need to periodically resync with a master clock anyway and the drift would be indistinguishable from noise. To be clear, no one would be changing the length of the second. An SI second is and always will be an SI second, and high-precision computing and science will be done with reference to SI seconds. But the elapsed time between consecutive seconds of civil time will be not quite an SI second, and will differ by an amount so small that for the purposes of day-to-day timekeeping is in effect indistinguishable.
- mrgriscom 12y agoAdding to my original comment: Getting rid of leap seconds and being done with it -- effectively setting civil time to atomic time -- may seem like an attractive alternative that achieves the same effect without the complications of transformation functions and skew rates, but it ignores that since the Earth's rotation is continuing to slow down, the offset between atomic and solar time is going to increase quadratically. While the first leap hour is 900 years out, the next one after that is only another 400, then 300, then 250... Someone is going to have to solve this problem for good eventually, and that will either involve applying the correction continuously as in my scheme, thus eliminating the quadratic compounding of the error, or eventually re-defining the second at some distant point in the future to match the Earth's rotation (and thus starting the situation over from scratch).
- AdamN 12y agoEverybody's talking about the time situation here, but what about the fact that the world's clocks will gain a second and the site announcing the fact isn't even signed and secure. It seems like the message should definitely have a cryptographic signature and that the site should be reachable via https.
- tehmaco 12y agoThis will probably resonate with people here[1]. A brilliant video by Tom Scott for Computerphile, where he starts to explain what coding timezones correctly is like and by the end of it is in full polite-mini-rant-mode :D [1] https://www.youtube.com/watch?v=-5wpm-gesOY https://www.youtube.com/watch?v=-5wpm-gesOY