Leap Second 2015: adusting for wibbly wobbly time-y wimey stuff
June 29, 2015 7:52 AM   Subscribe

The headlines are exciting: "Clocks to read 11:59:60 as time lords add leap second" and "Global markets spooked by looming 'leap second'," as June 30, 2015 will be extended for one second to keep Coordinated Universal Time (UTC) close to the mean solar time, or UT1 because the Earth is constantly undergoing a deceleration caused by the braking action of the tides. So why are markets bracing for trouble and some suggesting you avoid air travel at that time? There are always a few more bugs to work out, as seen when the extra second "crashed the web" in 2012, and global outage of computerised check-in systems used by Qantas and Virgin Australia.

Many tech companies are already prepared, according to various articles, press releases and blog posts, including Google, Amazon, Red Hat, SUSE, VMware, Cisco, and IBM.

But there's always something else:
“Almost every time we have a leap second, we find something,” Linux’s creator, Linus Torvalds, tells Wired. “It’s really annoying, because it’s a classic case of code that is basically never run, and thus not tested by users under their normal conditions.”
posted by filthy light thief (76 comments total) 18 users marked this as a favorite
 
Isn't it June 30th? I could be wrong, but I thought that was what I read.
posted by scottymac at 7:56 AM on June 29, 2015 [1 favorite]


Heh, that is my older sister's birthday. I shall take great glee in reminding her that not only is she older, her birthday is actually going to last longer.
posted by feckless fecal fear mongering at 8:03 AM on June 29, 2015 [3 favorites]


FreeBSD seems pretty chill about the upcoming leap second. Methinks Linus doth protest a bit too much.
posted by 1970s Antihero at 8:10 AM on June 29, 2015 [2 favorites]


You'd think by now people would know enough to code things to anticipate the occasional change in time. I remember Johnny Carson making a joke about adjusting his VCR clock for one of the leap seconds that was added.
posted by inthe80s at 8:10 AM on June 29, 2015


Hopefully this won't cause the intricate grid of laser tripwires surrounding the priceless Montague Emerald to be disabled just long enough for a ragtag band of criminals to snatch it in a daring heist
posted by theodolite at 8:12 AM on June 29, 2015 [45 favorites]


Most tech companies just "smear" the extra second over 24 hours in order to avoid any possible latent bugs. I don't get why that isn't the Linux default.

Also, computer clocks should really be in TAI (UTC without the leap seconds). There's no reason other than historical that computers should keep track of leap seconds at all. Maybe someone should set up an alternative NTP network that just skips them.
posted by miyabo at 8:23 AM on June 29, 2015 [1 favorite]


Surely this will cement Swatch beats (tm) internet time as the standard.
posted by chavenet at 8:24 AM on June 29, 2015 [11 favorites]


RIGHT my first thought about this was "how can i use this for A THRILLING CRIME".
posted by poffin boffin at 8:25 AM on June 29, 2015 [7 favorites]


I think we should get an extra like for today since we have this extra second.
posted by srboisvert at 8:26 AM on June 29, 2015 [4 favorites]


Can't we just nuke the moon from the right side and have the tides speed the earth back up?

Or drain some mountain reservoirs for a while?

Leap seconds are such a pain in the ass.
posted by ocschwar at 8:26 AM on June 29, 2015


You'd think by now people would know enough to code things to anticipate the occasional change in time.

Time is hard. Really hard. You just won't believe how vastly, hugely, mind-bogglingly hard it is. I mean, you may think it's tricky getting your character encodings to line up, but that's just peanuts to time.

(In all seriousness, though, the problem with leap seconds and software isn't the time change -- after all, we already change times twice a year for DST -- but the fact that there's an extra second where there used to be none. So you either have a duplicate timestamp -- wreaking havoc with everything that assumes that all times are unique, or you add a 61st second -- wreaking havoc with everything that assumes there are exactly 60 seconds in every minute.)
posted by neckro23 at 8:27 AM on June 29, 2015 [23 favorites]


I bet this wouldn't be a problem if we all used metric time.
posted by maryr at 8:29 AM on June 29, 2015 [3 favorites]


Couldn't this whole situation be avoided by making every second ever-so-slightly longer?
posted by Sys Rq at 8:30 AM on June 29, 2015 [2 favorites]


Leapsecond.com has a wonderful collection of oddball timekeeping stuff.
posted by Confess, Fletch at 8:30 AM on June 29, 2015 [6 favorites]


"FreeBSD seems pretty chill about the upcoming leap second. Methinks Linus doth protest a bit too much."

Last time it happened it caused a major outage:

http://www.techspot.com/news/49229-leap-second-bug-amazon-ec2-outage-brought-down-major-websites.html

EDIT: "It' being a leap second introduced in 2012.
posted by I-baLL at 8:35 AM on June 29, 2015


Leapsecond.com has a wonderful collection of oddball timekeeping stuff.

Oh my god this guy is the coolest
posted by theodolite at 8:36 AM on June 29, 2015 [6 favorites]


> Isn't it June 30th? I could be wrong, but I thought that was what I read.

Yep, per the USNO link in the post, it's 30 June 2015 at UTC 23:59:60. For those in the US, that's 7:59:60 PM Eastern Daylight Time (4:59:60 PM Pacific Daylight Time) tomorrow, Tuesday 30 June 2015.

NIST Best Practices for Leap Second Event Occurring on June 30, 2015.
posted by Westringia F. at 8:49 AM on June 29, 2015 [2 favorites]


Can't we just make one of the other seconds last twice as long?
posted by George_Spiggott at 8:49 AM on June 29, 2015 [3 favorites]


"Time is hard"...

Oh yes. Computerphile has a very heartfelt video by someone who has been there and still bears the scars...
posted by Devonian at 9:00 AM on June 29, 2015 [3 favorites]


Couldn't this whole situation be avoided by making every second ever-so-slightly longer?

Not without changing the ground state of cesium.
posted by maryr at 9:01 AM on June 29, 2015 [1 favorite]


Leapsecond.com has a wonderful collection of oddball timekeeping stuff.

That's an amazing site, almost deserves a post of its own.
posted by metaBugs at 9:01 AM on June 29, 2015


> Can't we just make one of the other seconds last twice as long?

Well, the standard is for a :60 second, but the NIST best practices paper does indeed say "NOTE: Not all clocks implement leap seconds in the same manner as UTC above. Some may use multiple 59s or 00s vice the 60s scheme above or even just freeze the time for one second."

But the problem isn't just a matter of how to represent it; it's how to keep things in sync. Whether it's inserting an extra beat or making one beat last twice as long, you're still introducing a hiccup in how machines keep time.
posted by Westringia F. at 9:01 AM on June 29, 2015


the problem with leap seconds . . . you either have a duplicate timestamp -- wreaking havoc with everything that assumes that all times are unique, or you add a 61st second -- wreaking havoc with everything that assumes there are exactly 60 seconds in every minute.

. . . Ennyway, I -- I just wannit to 'polygize fer wut happent yesterdy.
An' I'll tell you wut.
T'morrah -- I'll make the sun come up a half hour early
t' make up for the half hour late it wuz this mornin' . . .
Okay? Thanks.
-- The Janitor
 
posted by Herodios at 9:03 AM on June 29, 2015


Can't we just make one of the other seconds last twice as long?

Sure, and then in 3.15569^7 years, a year will be twice as long and the Earth will explode from the friction. Nice going.
posted by Celsius1414 at 9:03 AM on June 29, 2015 [1 favorite]


Spend your leap second here
posted by maskd at 9:18 AM on June 29, 2015 [1 favorite]


Digital clocks are precise down to the femtosecond. It's just not the SAME femtosecond.
posted by blue_beetle at 9:22 AM on June 29, 2015 [1 favorite]


So I myself asked, why not just smear the time differential over a long enough period that it doesn't matter? Like, we adapt to clock being wrong all the time, why not just be "intentionally wrong"?

Answer is that time isn't just about now, it's also about then. More specifically you need to be able to link/correlate events that happened in the past. Just chalking an intentional error to unintentional drift has the issue that for the period of drift nothing can be adequately correlated. If it's over a 24 hour period that's a long time to be outside of correlatability.
posted by effugas at 9:23 AM on June 29, 2015 [2 favorites]


Great whickering stallions!
posted by SPrintF at 9:25 AM on June 29, 2015


Google does indeed 'smear' the leap second over the entire day, making each second a few microseconds longer than the last. That means All Of Google is slightly adrift for the duration, but All Of Google is entirely in synch with itself. And that's what matters.
posted by Devonian at 9:41 AM on June 29, 2015 [2 favorites]


I wish we would just save these up and then insert an intercalary month. The Romans knew what they were doing.
posted by kiltedtaco at 9:43 AM on June 29, 2015 [2 favorites]


Re why we use UTC and not TAI / GPS / etc.: I believe, though I can't currently find my notes relating to this (so: grain of salt), a non-trivial number of countries have laws requiring their time standard be tied to solar time. You'd have to get them to change their laws before you could switch over; in light of how politics work, dealing with a cumbersome leap second every handful of years looks totally reasonable in comparison.

(At a previous job I saw a lot of broken third-party parsers who would throw up their hands when given a timestamp of 23h 59m 60s. Much like running into address-handling engines that demanded a house number or a street name, it was fun in a very limited "oh hell, I have to work around this" way.)
posted by introp at 9:48 AM on June 29, 2015 [1 favorite]


I have to say, I very much like being places where knowing roughly when dinner is served is the major timekeeping task of the day.
posted by Devonian at 9:51 AM on June 29, 2015 [2 favorites]


Surely this will cement Swatch beats (tm) internet time as the standard.
Oh, crap. Thanks, I've just tweeted at Swatch to find out what their guidance is for handling leap seconds in .beats. I'll let you know if they get back to me.
posted by phooky at 10:03 AM on June 29, 2015 [3 favorites]


Couldn't this whole situation be avoided by making every second ever-so-slightly longer?

Not without changing the ground state of cesium.


Huh. Well, that's silly. Instead of measuring the thing it's meant to be measuring, a second is measuring some other, coincidentally similar thing, but the coincidentally similar thing isn't similar enough, and we know exactly how not similar enough it is, so we have leap seconds?

Why don't the nuclear geniuses who thought this up save everyone else the hassle and just use leap cesiums while the rest of us use seconds that are actually a second long?
posted by Sys Rq at 10:16 AM on June 29, 2015 [1 favorite]


Hey, FLT beat me to this post! And without even a Previously to go with it! But it's a much nicer post than I would have made.

Some of us pulsar astronomers are apparently well prepared for this leap second, because our clock table files have included this leap second for a few months now - but if someone in the data chain has not yet updated their software, all our pulsars will appear to have gone berserk next week. Fun.

Also, it's a rare chance to fill the unforgiving minute with *more* than 60 seconds' worth of distance run!
posted by RedOrGreen at 10:23 AM on June 29, 2015 [2 favorites]


Couldn't this whole situation be avoided by making every second ever-so-slightly longer?

I am not going to count Mississippiis

I won't
posted by the uncomplicated soups of my childhood at 10:24 AM on June 29, 2015 [2 favorites]


Yep, per the USNO link in the post, it's 30 June 2015 at UTC 23:59:60.

Awesome, that's my fortieth birthday so I shall assume it is all for me.
posted by shelleycat at 10:25 AM on June 29, 2015 [2 favorites]


In all seriousness, though, the problem with leap seconds and software isn't the time change -- after all, we already change times twice a year for DST -- but the fact that there's an extra second where there used to be none.

No, the problem is, despite the fact that we've repeatedly had problem with this, application writers persist in the delusion that the universal civil clock that we use only has and will only have 60 seconds per minute, which has not been true since 1972.

If we'd just accepted that this could happen and written the code to accept it, then it wouldn't be such a crash bug. But nope, no such thing as Second 60. Second 00 comes after Second 59.

So, when Second 60, a perfectly valid second in UTC, the world's clock system, does show up, too many thing go *foom*.

And, as the Earth's rotation continues to slow thanks to tidal drag, it'll happen more and more often. Right now, it happens about every 800 days, but because it's only measurable, not predictable, we can't tell you exactly when UT1 will drift too far from UTC and the next leap will happen.
posted by eriko at 10:30 AM on June 29, 2015 [3 favorites]


Can't we just nuke the moon from the right side and have the tides speed the earth back up?

Good god, no. That's how you get Space: 1999. Do you want Space: 1999?
posted by Mr. Bad Example at 10:34 AM on June 29, 2015 [5 favorites]


We generate 60 day Flight Dynamics products on Fermi every week on Monday, and the leap second has been affecting them for about 57 days. We use STK and that expects data on a an even minute interval, and the leap second throws that off. We also take care not to schedule our TDRSS contacts over the leap second.

We're planning on staffing our Mission Operations Center before and during the leap second, and that's cool because it means that I can sleep late tomorrow and work second shift.
posted by Rob Rockets at 10:37 AM on June 29, 2015 [7 favorites]


This is why I make a point of facing East to inhale and West to exhale.
posted by George_Spiggott at 10:45 AM on June 29, 2015 [5 favorites]


scottymac: Isn't it June 30th? I could be wrong, but I thought that was what I read.

Westringia F.: Yep, per the USNO link in the post, it's 30 June 2015 at UTC 23:59:60.

Ah, thanks for the correction!


Confess, Fletch: Leapsecond.com has a wonderful collection of oddball timekeeping stuff.

theodolite: Oh my god this guy is the coolest

Wow, how did that not come up in searches for Leap Second stuff? His site should be the first result!



RedOrGreen: Hey, FLT beat me to this post! And without even a Previously to go with it! But it's a much nicer post than I would have made.

Thanks, and sorry about the lack of previously-ies. To address that: posted by filthy light thief at 11:02 AM on June 29, 2015 [1 favorite]


I spent several months once trying to align a moderately complicated system which had been running internationally for several years without a well defined policy on time management or the storage of timestamps. It was horrific. And it had become horrific even though the OS vendor was consistent (although versions weren't), the DB vendor was consistent (although versions weren't) and people had generally stuck to defaults or made sensible decisions based on local best practice or cultural norms. In fact respecting cultural norms should be a disciplinable offence imho.

Once you get beyond two machines recording the order things happened is actually fairly tricky, unless you plan it carefully. Once you get beyond two locations it becomes hard, even if you plan it carefully. People seem to find this a source of constant surprise.
posted by samworm at 11:49 AM on June 29, 2015


we can't tell you exactly when UT1 will drift too far from UTC and the next leap will happen.

Maybe, just maybe, that next leap... will be the leap home.

</ziggy>
</oh boy>
posted by Rock Steady at 11:58 AM on June 29, 2015 [3 favorites]


> I wish we would just save these up and then insert an intercalary month. The Romans knew what they were doing.

How about we just have thirteen 28-day cycles (AS NATURE INTENDED), and cap off each year with an intercalary day? They could even call it "A New Day" or somesuch poetry.
posted by Johann Georg Faust at 12:15 PM on June 29, 2015


Totally agree; I am much in favor of switching to 13 months. If you're going to define a unit of time based on the moon (approximately), you better make it actually match the length of a lunation.

Makes more sense than DST.
posted by kiltedtaco at 12:32 PM on June 29, 2015


Not without changing the ground state of cesium.

Can we do a feasibility study? I think this might be easier than getting all programmers (this one included) to code time correctly.
posted by MikeKD at 12:56 PM on June 29, 2015 [3 favorites]


I work in technology in an electronic trading firm, and the amount of time I've had to have my team spend on one silly second this month would be alarming to anyone who hasn't been to this rodeo before. We use PTP to keep our most critical clocks accurate to within 10 nanoseconds -- on this scale, a second is a huge amount of time for something bad to happen.

To put it in perspective: the ratio between 10 nanoseconds and 1 second is roughly that between 1 second and 3 years. Think about watching a clock go tick... tick... tick... every second, and then all of a sudden you jump three years into the future. That's what we're worrying about.

The reason this is of particular concern to the finance industry, as noted in one of TFAs, is that we work on unjustifiably minuscule time frames,and this is the first leap second that will be encountered during trading hours since trading went electronic. The major US equities markets will be closed, but AP markets will be open, or just opening, right at that time, and extended hours trading around the world will be underway.

What's been most darkly amusing to me about this is the many various ways in which markets are adjusting. Some aren't opening until after. Some are halting for the event. Some are operating through it. And there is even more disparity in how the second itself is being handled. I have on my desk now a ridiculously complicated table from an FIA memo detailing how many markets are handling this and, well... it's, as I say, darkly amusing. Some places are introducing second :60, some are repeating :59, some are smearing the seconds before, some are smearing after, over various lengths of time, there is zero consistency.

I don't expect planes to fall out of the sky Tuesday night, but I do expect Wednesday to be a very busy day for a lot of people in various industries.

Time is hard, yo.

(And it's past time I got out of this industry.)
posted by jammer at 1:26 PM on June 29, 2015 [10 favorites]


jammer: darkly amusing. Some places are introducing second :60, some are repeating :59, some are smearing the seconds before, some are smearing after, over various lengths of time, there is zero consistency.

But, but, there's *already* a standard here, 23:59:60 - why are these people reinventing the wheel? And repeating :59, really? So now different timestamps will not correspond to unique times? That sounds insane, not just darkly amusing.

(If I were a nefarious trader on an exchange that did this, I'd be looking into the interesting possibilities of buying a stock at :59.75 and then selling it on the next second with a timestamp of :59.25, and what arbitrage opportunities that might open up. These guys supposedly trade over milliseconds and microseconds, and worry about minimizing nanosecond differences in travel time to exchanges. They're going to just repeat a whole second?)
posted by RedOrGreen at 1:52 PM on June 29, 2015 [2 favorites]


So...

What are y'all planning to do with your extra second?
posted by duffell at 1:55 PM on June 29, 2015


RedOrGreen: But, but, there's *already* a standard here, 23:59:60 - why are these people reinventing the wheel? And repeating :59, really? So now different timestamps will not correspond to unique times? That sounds insane, not just darkly amusing.

Yes, it is insane. When I first started surveying how this was going to go down, that was my first reaction as well. One of the things I've been having to worry about is how our processes are going to react when we're talking to somewhere in the world that's trying to tell us it's 23:59:59 again.

I have no good answers as to why this is that aren't also bundled up with a lot of the general negativity and burnout I'm feeling with being in this industry on top of the moral qualms I've struggled with for years. About the most I can say without too much editorial color is that the trading industry is very bad about having standards for anything, or adhering to them when they even exist, because everyone needs to have their special sauce and keep it secret from everyone else. On top of that, while there are some really brilliant quants and low-latency programmers, the industry seems to have a chronic problem with having decent operational staff. It's not "worth" the money to pay for good sysadmins and engineers who know how to handle these things correctly, so you have a bunch of halfwits doing whatever comes to mind first, and not bothering to check with the rest of the world because That's Not How We Do Things(tm).
posted by jammer at 2:02 PM on June 29, 2015 [4 favorites]


So...

What are y'all planning to do with your extra second?


Sleep, man. The answer is always sleep.
posted by maryr at 2:10 PM on June 29, 2015 [1 favorite]


And remember, it's not that long until 03:14:08 UTC on 19 January 2038.
posted by Devonian at 2:18 PM on June 29, 2015 [3 favorites]


[Corrected the date in the post, carry on.]
posted by cortex (staff) at 2:26 PM on June 29, 2015 [2 favorites]


Computer time is a seriously complicated problem. It sounds easy, but the devil is in the details. This video from Computerphile is mostly an extended rant about how hard it is, and it's hilarious. It's mostly about timezones, but it gives insight into how much complexity goes into something as simple as keeping time on a computer.
posted by water under the bridge at 5:35 PM on June 29, 2015


Woot! I get to keep my rental car an extra second, for free! Why wasn't I this excited about the extra hour I got last fall?
posted by wierdo at 6:09 PM on June 29, 2015


23:59:59 vs. 23:59:60 is irrelevant for most computers. Unix-based computers count the number of seconds since midnight UTC, January 1st, 1970. As I write this there have been 1,435,627,122 of them. The big problem is that leap seconds don't count: from the computer's perspective, the same second happens twice. You can't stick a new time in the middle any more than you can stick a new whole number in between 9 and 10: it doesn't make sense.

We don't have to do this. As many above (e.g. miyabo) mention, you could keep on counting during leap seconds. But there are some big problems with this! For instance, since we can't predict with perfect certainty how fast the earth will rotate in the future, we don't know when leap seconds will happen. So suppose you want to tell the computer that something will happen at 9am on December 1st, 2016. There would be no way of representing this exact time with accuracy, since we don't know if that would be second number 1,480,600,800 or 1,480,600,801 or 1,480,600,802. Since most of the times we care about in the world are "civil times" that have meaning to people, we stick with leap-second-having and human-relevant UTC.

And why can't we change the length of seconds every once in awhile to be 1/86400th of a day? Scientists would hate it. For one thing, we'd keep needing to adjust the textbooks: how fast is acceleration due to gravity? What's the speed of light? Hope you bought the new edition!
posted by goingonit at 6:26 PM on June 29, 2015


There is so not any fundamental problem in making software that can handle a leap second any more than there is a fundamental problem with handling leap day. It requires thinking carefully about the difference between a date and a time interval. The only difficulty is that we rarely demand software to be written carefully and thoughtfully, and even if one endeavors to do so, it's often forced to interact with lots of software that wasn't.
posted by kiltedtaco at 6:52 PM on June 29, 2015 [1 favorite]


The problems brought up in the computerphile video are real but are the ones that icu already deals with (other than last minute changes like Libya's.) The scary stuff is what icu doesn't handle well. Want to know how long til "this time next week"? Good luck. There might be none or two of them.
posted by jewzilla at 6:53 PM on June 29, 2015


There is so not any fundamental problem in making software that can handle a leap second any more than there is a fundamental problem with handling leap day.

I think one big difference is that leap seconds don't follow a set schedule. Leap days do, and it's easy to write a program to calculate something like how many days there are left in this century (in the Gregorian calendar); you just do the math. It doesn't work that way with leap seconds; it is fundamentally impossible to write a program to calculate how many seconds there are left in this century (UTC), because we don't actually know how much the Earth's rotation will slow down during that time period.
posted by water under the bridge at 10:11 PM on June 29, 2015 [1 favorite]


But, but, there's *already* a standard here, 23:59:60 - why are these people reinventing the wheel?

There's an ancient saying in the computer field, usually (but probably apocryphally) attributed to Grace Hopper:

"The wonderful thing about standards is that there are so many to choose from."
posted by Mr. Bad Example at 4:14 AM on June 30, 2015 [4 favorites]


My telco's network had an ethernet outage which was being speculated as leap-second related today. I am well outside the escalation path, but the notes I saw showed patches for the leap second affecting some generations of hardware but not others.
It really shows the differences between humans and machines. "Leap second, LOL, whatevs" versus "Drop all my bits in an untidy pile, hope me".
posted by bystander at 6:32 AM on June 30, 2015 [1 favorite]


Heh -- the NIST WWV radio station has an advisory that they're broadcasting at ~4min past the hour -- or at least they did at 14:04 UTC -- about their addition of the extra second tonight. (I'll try to record it the next time it comes around, because I am a GIANT NERD; if I catch it, I'll share a link to it here.)

If you want to listen to the time signal but don't have a shortwave radio, you can try to hear it using a Web-SDR receiver such as those on websdr.org, globaltuners, or dxzone. To hear the NIST broadcast you'll want to use a receiver in N America, as close to Ft Collins or Hawaii as possible, and tune to the internationally allocated frequencies for time broadcasts: 2.5/5/10/15/25 MHz (lower frequencies have longer range & are better at night). You can sometimes hear other countries' time signals using receivers elsewhere, too.

(Note that not all web-SDRs receive all bands. EG, the only N American receiver on websdr.org listed as covering 5/10/15 MHz is the Great Lakes Listening Post, http://blerp2.dyndns.org:8901/. You'll hear it more clearly if you set the bandwidth down to 3-6kHz.)

Alternatively, you can always call the clocks.
posted by Westringia F. at 7:59 AM on June 30, 2015 [1 favorite]


Oh wow, I hadn't thought of the radio station that transmitted the time and such for a while. When I used to run the boards at my college radio station for the local Met Opera radio broadcasts, that set frequency would broadcast date and time information when the Met wasn't on.
posted by filthy light thief at 8:26 AM on June 30, 2015


Not without changing the ground state of cesium.

Can we do a feasibility study? I think this might be easier than getting all programmers (this one included) to code time correctly.


It's ridiculously easy to change the ground state(s) of cesium (or any other atom.) Anybody got a magnet?

I've worked on atomic clock development a bit, enough to know that the hard part is isolating the atoms from any fields (at some performance level, gravitational redshift from the earth's gravity, and blackbody radiation from the inside of your vacuum chamber start to count, and can change with the tides or the temperature of the lab) or other atoms or particles, any or all of which will shift the states somewhat.

All clocks drift. There's no objective way to measure a second -- you just pick the clock you're going to trust.
posted by OnceUponATime at 9:11 AM on June 30, 2015


> I'll try to record [the WWV leap-second advisory] the next time it comes around, because I am a GIANT NERD; if I catch it, I'll share a link to it here.

As promised.
posted by Westringia F. at 9:16 AM on June 30, 2015 [3 favorites]


I have to say, I very much like being places where knowing roughly when dinner is served is the major timekeeping task of the day.
posted by Devonian at 12:51 PM on June 29

I don't know why but I read that in Winnie the Pooh's voice. (Oh bother.)
posted by dances with hamsters at 10:08 AM on June 30, 2015 [1 favorite]


It doesn't work that way with leap seconds; it is fundamentally impossible to write a program to calculate how many seconds there are left in this century (UTC), because we don't actually know how much the Earth's rotation will slow down during that time period.

I agree this is fundamentally impossible due to the uncertainty in the Earth's rotation. I think it's worth noting that this type of task is almost never ever necessary or useful. I can't come up with any case where I need to know the number of cesium oscillations until a specified civil date more than a year in the future, to more than second accuracy. If I'm talking about physical systems I always care more about the cesium oscillations, and civil time is irrelevant. If I'm talking about civil time spans then it doesn't matter what cesium is doing in the meantime.
posted by kiltedtaco at 10:28 AM on June 30, 2015 [2 favorites]


But that's just the thing. Computers are tied to civil time, not to cesium oscillations, for no good reason. We DON'T adjust computer's internal clocks (the ticker inside the OS kernel) for daylight savings or timezone shifts... but we DO for leap seconds. It makes no sense.
posted by miyabo at 11:33 AM on June 30, 2015


but we DO for leap seconds. It makes no sense.

For most "normal" computers, we actually don't. See this discussion on OpenBSD. Quote:

The sky will fall, civilization will end, and dinosaurs will roam
the earth again. Well, maybe not.

Neither the OpenBSD kernel nor OpenNTPD handle leap seconds in any
way. So what will happen?

After the leap second, your OpenBSD system's time will be off by,
well, one second. Gasp, shock. Let's say you synchronize your
clock with ntpd against a server that does have the correct time.
At the next poll, i.e. within about half an hour, ntpd will notice
the offset and correct it, which will take a few minutes. That's
it. (I expect ntpd will drop down to a short poll interval and the
frequency correction will fishtail a bit since it's a differentiator
reacting to a jump.)

Unless you obsessively watch your ntpd, you won't notice a thing.

posted by DreamerFi at 11:43 AM on June 30, 2015 [1 favorite]


That is exactly what I'm talking about. The OS kernel is getting adjusted for the leap second (by an outside process, but still). Why does NTP use UTC instead of TAI?
posted by miyabo at 11:52 AM on June 30, 2015


This Is Just To Say

I have used up
the leap second
that was in
your calendar

and which
you were probably
saving
for tonight

Forgive me
it was fun
so entertaining
and so short
posted by Hairy Lobster at 2:53 PM on June 30, 2015 [5 favorites]




Here is a recording of the WWV broadcast during the leap-second. It's not the clearest, unfortunately, and TBH not all that interesting -- there's no announcement or marker, just a tone that comes one second later after the voice announcement than it normally would.

Last night we went to the Naval Observatory to watch the USNO Master Clock display. There was a small crowd gathered; one of them, a USNO intern, mentioned that the clock should read :59 twice (rather than :60). But it didn't: it just kept chugging along at the usual pace, 7:59:57, 7:59:58, 7:59:59, 8:00:00, 8:00:01....

And then it went black.

When the display came back up a few minutes later, it had forgotten about daylight saving time, and showed the hour as 7pm. Fortunately for the USNO, there weren't any local news media around to do a story on the leap-second by taking video of the Master Clock's display; just a bunch of disappointed nerds.

But I do find it kinda hilarious that after all the hand-wringing about systems not tolerating the leap second, the clock itself went down.
posted by Westringia F. at 6:18 AM on July 1, 2015 [5 favorites]


Westringia F., thanks for the update! Here are some more updates from various sources:

Leap Second sparks Amazon crash and confuses Twitter
Thousands of websites which use Amazon Web Services crashed while users reported problems with Android and Twitter as the leap second was added to atomic time
Leap second causes Internet hiccup
Some 2,000 networks stopped working just after midnight Coordinated Universal Time (UTC), said Doug Madory, director of Internet analysis with Dyn, a company that studies global Internet traffic flows.

Nearly 50 percent of those networks were in Brazil, which may indicate that Internet service providers use a common type of router that may not have been prepared for the leap second, he said.

Most of the networks quickly recovered, which may have required just a reboot of a router, Madory said.

The Internet's global routing table, a distributed database of networks and how they connect, contains more than 500,000 networks, so the problems affected less than a half a percent, Madory said.
How Indian stock markets escaped Tuesday's leap second curse
There was no impact of ‘leap second’ on Indian trading systems, as exchanges added an extra second before the opening of market hours. The leap second had made markets like in the US, Australia, Japan and parts of Asia uneasy, as the extra second was to be added during trading hours, or at the start of market hours.
Leap second 'stops' time, nothing happens
When the second hand reached 6 p.m. MDT Tuesday, time "stopped" for a second. But much like Y2K, the fear of a possible meltdown fizzled out as soon as the clock started up again.

One second was added Tuesday evening to Universal Time, a decision made by the International Time Bureau in an effort to keep the clock synced with earth's rotation, which has slowed a bit since the last leap second in 2012.

For those who own radio-controlled clocks, a radio signal in Northern Colorado told the second hand to pause before ticking.
Yup, that's pretty accurate, as far as I see. Regarding trading, I could only find a current article on the Indian stock markets, and there's no news from Qantas or other airlines.
posted by filthy light thief at 7:24 AM on July 1, 2015


Markets around the world managed the leap second in different ways, and it passed without incident. Some planned ahead and opened (or stayed open) as normal, while others closed or opened with a short delay to avoid potential issues.

And the world-wide tizzy becomes a "meh," as it seems that everyone learned good lessons from 2012 and were better prepared this time.
posted by filthy light thief at 11:40 AM on July 1, 2015 [1 favorite]


« Older Boiled/Braised, (Stir-)Fried, Grilled...   |   Job's a good 'un Newer »


This thread has been archived and is closed to new comments