The Leap Second Is Here! Are Your Systems Ready?

Tmack writes "The last time we had a leap second, sysadmins were taken a bit by surprise when a random smattering of systems locked up (including Slashdot itself) due to a kernel bug causing a race condition specific to the way leap seconds are handled/notified by ntp. The vulnerable kernel versions (prior to 2.6.29) are still common amongst older versions of popular distributions (Debian Lenny, RHEL/CentOS 5) and embedded/black-box style appliances (Switches, load balancers, spam filters/email gateways, NAS devices, etc). Several vendors have released patches and bulletins about the possibility of a repeat of last time. Are you/your team/company ready? Are you upgraded, or are you going to bypass this by simply turning off NTP for the weekend?" Update: 07/01 03:14 GMT by S : ZeroPaid reports that this issue took down the Pirate Bay for a few hours.

Comments

Irony

[bughunter]

Leap years = no problem.

Leap seconds = kernel panic.

I fear for teh internets if we try a leap millisecond.

Re:Irony

[at10u8]

The time service bureaus used to insert leap milliseconds at almost any time. See the bottom plot at http://www.ucolick.org/~sla/leapsecs/amsci.html where there were 29 leaps in 3 years.

Re:Irony

[ericloewe]

It was not the largest of timer overflows that killed them, but the tiniest leap second...

Re:Irony

[Anonymous Coward]

But with Linux, things get fixed really fast. Apparently they get fixed, but not deployed? I mean really - if this was fixed a year ago, what is the excuse for still running the old problematic version? I'm interested to hear what the excuse is - because it will probably sound a lot like the things you all flame Windows users for...

Re:Irony

[0123456]

I'm interested to hear what the excuse is - because it will probably sound a lot like the things you all flame Windows users for...

A lot of Linux systems are on private networks and have to be up 24/7. Dealing with a known bug is considered less problematic than installing a new OS version and invalidating all the testing which has proven that the system can run 24/7 over the last few years.

So I guess you're right, it is very similar to the reasons why there are many unpatched Windows systems out there.

Re:Irony

[fuzzyfuzzyfungus]

Jokes aside, the issue is that leap seconds are not deterministic.

TAI, based on whatever flavor of atomic clock is currently the going standard, is markedly more regular than the observed time based on the movement of the earth(UT1). UTC ticks at the same rate as TAI; but is supposed to correspond to UT1, which ticks at an unpredictable rate. So, whenever UT1 and UTC drift too far apart(DUT1 approaches .9 seconds), UTC gets a leap second. The UTC tick rate is constant; but the leap-second days are 1 second longer.

Obviously, we should just abandon this UTC nonsense.

Re:Irony

[pla]

I mean really - if this was fixed a year ago, what is the excuse for still running the old problematic version?

The excuse? I have a file server and a router that run 24/7/365.24 (+1/86400, on occasion), and they just work. I have no interest in even logging into them, and they will remain "stock" systems until either a critical SSL vulnerability (in the case of the router) or I absolutely need a feature not possible with that old of a system. And when I say "old", I mean, talking "Slackware 4" here until about a year ago.

One of the nice things about Linux - It just works. You don't get random reboots every two weeks when Microsoft decides you must install this particular update, It doesn't get "crufty" the same way the Windows registry does, it doesn't suddenly fail to boot one morning (though in fairness, the fact that we never shut them down probably leads to a bias in that regard). It just works, day after day, year after year. If it worked yesterday and no hardware failed overnight, it will work today.

Now... If you want to call that something that we complain about in Windows... Hey, I'll admit it, I want my software to "just work". Whether that means a Linux server that never goes down, or an XP desktop environment that (for the 18-24 months between puking) everything supports, I just want my hammer to pound nails and my crowbar to pull them back out, and I don't care if my screwdriver believes in Buddha or Jesus or Xenu.

Re:Irony

[techno-vampire]

Dealing with a known bug is considered less problematic than installing a new OS version...

If there's a kernel bug to be patched, you download and install a newer kernel, with the bug patch, then reboot (at some time when the outage will be the least inconvenient) into the new version. And, if you really can't afford the downtime, there are ways to get a new kernel running without even that. No need for a complete OS upgrade, just to get a more recent kernel.

Re:Irony

[Anonymous Coward]

The Windows and the DOSes weren't designed for Y2K

The Zune wasn't designed for leap-year

Let's hope that MS has a large enough team at work on the Leap Second Status Wizard for Win 8 and Surface. That could well be the killer app that differentiates those products. It's not known if older products can be patched for this advanced capability.

http://www.zuneboards.com/forums/showthread.php?t=38143

Re:Irony

[binarylarry]

Ziggy must be on the sauce again.

Re:Irony

[0123456]

And what do you do when the kernel change causes your system to start crashing, when it had previously operated for years with no failures?

An acquaintance supports a system which has been in operation for years and breaks every time there's a leap second (not because of the Linux kernel but other software and hardware issues). That means every few years he spends a couple of hours rebooting the servers and verifying that it's up and running again afterwards. Fixing the software would mean a substantial amount of development work followed by weeks of testing.

Re:Irony

[techno-vampire]

And what do you do when the kernel change causes your system to start crashing, when it had previously operated for years with no failures?

I'd really, really love to respond by saying that That Just Doesn't Happen. Alas, I know better. My laptop is currently running Fedora 16 with a PAE kernel from Fedora 14 because every 3.x kernel I've tried on it hangs during boot while trying to do something with my card reader. And, if I have a card in the reader, it ends up rebooting itself. About all I can say is that the situation you describe is (mercifully) rare, and if you do find yourself stuck with that, about all you can do is turn off ntpd before the leap second, and turn it back on later.

Re:Irony

[Anonymous Coward]

I had this problem occur with a DL360 (G4 maybe?). I'd upgrade the kernel and then the system would randomly hang in about 2-3 days. No error, no warning, just a hard lock up with nothing in the error logs. I'd try a new kernel now and then and the same problem every time, requiring me to roll back. After about a year or so, one of the kernels I tried actually gave me a warning about the SCSI controller misreporting some parameter and to perhaps update my SCSI firmware. After updating the firmware, no more problems.

Re:Irony

[ganjadude]

the feds of every country cant bring TPB down but a leap second can??? now THATS irony

Re:Irony

[grcumb]

And what do you do when the kernel change causes your system to start crashing, when it had previously operated for years with no failures?

Er, you restart with the older kernel, which is right there on the grub boot menu.

... Sorry, was this a trick question or something...?

Re:Irony

[Anonymous Coward]

One of the nice things about Linux - It just works. You don't get random reboots every two weeks when Microsoft decides you must install this particular update, It doesn't get "crufty" the same way the Windows registry does, it doesn't suddenly fail to boot one morning

Lies.

One of the main reason's why I've lost so much respect for Slashdot and the FLOSS community in general is the massive amount of anti-Windows lies that get repeated over and over. If Linux was truly better then you wouldn't resort to such things.

Microsoft doesn't force anyone to update. You are in control of your updates in Windows, just like in Linux.

Windows doesn't suddenly "fail to boot" for no reason.

The registry doesn't get "crufty". That is just a baseless attack that has no meat behind it. Please explain the science of "cruft", how it works, how it impacts performance, and how other OSes aren;t affected by "cruft".

Re:Irony

[techno-vampire]

If it hung after several days, I'd probably never even notice it, because my laptop's rarely in use for more than a few hours. Alas, with any 3.x kernel, it hangs during boot. Still a firmware update might be worth looking into.

Re:Irony

[Anonymous Coward]

One of the nice things about Linux - It just works. You don't get random reboots every two weeks when Microsoft decides you must install this particular update, It doesn't get "crufty" the same way the Windows registry does,

Why are you comparing a single purpose Linux server to your Windows desktop for? You can achieve the same results with a Windows server configured the same, the firewall turned on and auto updates off. If you can write off local exploits by unprivileged users and as long as OpenSSH security fixes are still being back ported to your OS, and no other services are exposed to an untrusted network, I can't disagree with you. However, like I said, you can do the exact same with a Windows system and the same constraints.

BTW, I dare you to post "sudo find /" from your Linux desktop so we can point out your "cruft".

Re:Irony

[BitZtream]

I'd really, really love to respond by saying that That Just Doesn't Happen. Alas, I know better.

Do you? You really sound like you think Linux is so great that it somehow acts differently than every other engineered item in the known universe.

Re:Irony

[Raenex]

I agree with the AC replies. I run both Windows and Debian Linux and your post is full of propaganda.

Re:Irony

[Hognoxious]

Microsoft doesn't force anyone to update. You are in control of your updates in Windows, just like in Linux.

Nope. I have windows update set to "check but ask" and occasionally I find that it's restarted due to updates without even informing me.

Re:Irony

[Hognoxious]

I'm running Centos 5.3[1] and it's apparently running fine. If I'd known about this I might have sat and watched it tick over.

[1] Yes, I know. Upgrading (or maybe trying out SL) is on my copious free time stack.

Re:Irony

[kelemvor4]

Dealing with a known bug is considered less problematic than installing a new OS version

Everybody makes mistakes sometimes.

Re:Irony

[Anonymous Coward]

My windows sever 2008 install has been running for almost a year now...

Re:Irony

[Anonymous Coward]

I also run both, but more Linux than Windows. The Windows machines are always [locking|rebooting|nagging|grinding to a halt], while the Linux machines just hum along. The minority OS creates the majority of problems.

Re:Irony

[Anonymous Coward]

I don't have that much experience with Fedora, but can't you just turn that driver into a module, and then don't load it automatically at boot? That way you can research the issue and make modifications to the module while you are running the rest of the system.

Re:Irony

[Raenex]

I tell it to ask me, and I've never experienced this. Maybe you're under a command & control botnet.

Re:Irony

[techno-vampire]

I don't know; I haven't done any programming in almost 20 years, and when I did, it wasn't that type of thing. There's a bug report open on it, and I'm not the only one suffering from it, so there may be some hope. And, I'm going to research the possibility of a firmware update because if there is one, it might help.

Re:Irony

[Hognoxious]

Maybe you're under a command & control botnet.

I guess that's one name for them... I'm sure they've been called many more.

http://www.microsoft-watch.com/content/operating_systems/windows_updates_sneaky_updates.html

Re:Irony

[Anonymous Coward]

This just in: Anti-piracy agencies around the world start lobbying for more leap seconds!

Re:Irony

[damonlab]

DL360 is a rackmount HP server, not a laptop.

Re:Irony

[Stealth210]

One of the nice things about Linux - It just works. You don't get random reboots every two weeks when Microsoft decides you must install this particular update, It doesn't get "crufty" the same way the Windows registry does, it doesn't suddenly fail to boot one morning (though in fairness, the fact that we never shut them down probably leads to a bias in that regard). It just works, day after day, year after year. If it worked yesterday and no hardware failed overnight, it will work today.

You are so full of it. You like being that smug though, don't you? The reason you have issues with your Windows machines is because you set them up to fail with poor hardware, poor administration, or both. I have a 2003 Server machine as my fileserver and VM host that has been up for(and I had to check this) 512 days(hah, what a good number)

Signed, a Linux user since Slack 3.1.

Re:Irony

[Vegemeister]

The registry doesn't get "crufty". That is just a baseless attack that has no meat behind it. Please explain the science of "cruft", how it works, how it impacts performance, and how other OSes aren;t affected by "cruft".

Other OSes have package managers. Windows does not. "Cruft" is the result of the installation and removal of software in the absence of a package manger.

Re:Irony

[Raenex]

I wasn't aware of that. That's pretty terrible, though they claim it's only for updating Windows Update itself.

Re:Irony

[dbIII]

Leap years = no problem.
Well, it did hit Microsoft out of the blue (azure) but Zune they may be able to deal with this tricky calendar.

Re:Irony

[thogard]

But we can wait 6 months to put in the leap seconds at New Years Eve when most of the worlds business is not active, unlike Jun 30/July 1 time which tends to be very busy for most of the world around midnight UTC.

Re:Irony

[dbIII]

Please explain the science of "cruft"

A fucking great big enormous file that takes unacceptable time to parse.

Re:Irony

[Anonymous Coward]

Microsoft doesn't force anyone to update. You are in control of your updates in Windows, just like in Linux.

Nope. I have windows update set to "check but ask" and occasionally I find that it's restarted due to updates without even informing me.

The grandparent was talking about a server. Ever heard of WSUS?

Re:Irony

[Mark Hood]

Not a trick question - but now you're exactly where you were before you tried to fix it...

The OP was pointing out that just loading the new Kernel isn't always an option - depending on the environment, you might find it easier to stick with a working, well-understood configuration than introduce the risk of the unknown.

Re:Irony

[Anonymous Coward]

If you can do just that without any trouble, why upgrade in the first place?

Re:Irony

[miknix]

Clock: inserting leap second 23:59:60 UTC

My Gentoo server is still going fine :)

Re:Irony

[profplump]

Beside the prolonged inaccuracy in civil time keeping (which may or may not be important for your application) some years require more than one leap second. So unless you want to double up on December 31 you need a second date on which we can add a second.

Re:Irony

[kasperd]

Not a trick question - but now you're exactly where you were before you tried to fix it...

No. You know something you didn't know before you tried it. Use that knowledge to research the newly identified problem.

In most cases the update goes fine and you won't need to spend more time on it. In the rare cases where the update does break, you'll have to spend some more time to work out all the problems.

If the only difference between the old and the new kernel is the few lines of changes to fix a known bug, then it is highly unlikely to introduce new problems. If however you switch to a new kernel, which not only has the bugfix you need, but also has a ton of new features as well as a rewritten version of a subsystem that you heavily depend on, then the update is more likely to introduce problems.

This is why you will see people starting out from one version and then keep applying bugfixes and nothing else.

Re:Irony

[Anonymous Coward]

Many Linux users don't download and compile new kernels themselves, they rely on some "distribution" to do that for them.
Unfortunately many of those distributions go unmaintained a lot quicker than Windows versions, and no more updates appear.
To move on to a new version is a major operation which will often be postponed, especially when the system works well and is not on the internet.

Re:Irony

[thogard]

Doubling up has already happened.

Re:Irony

[Anonymous Coward]

I think most of the IT lifers here, yourself included, just don't get it. If your software crashes under a new kernel, the time spent figuring out if it was the kernel, a code bug, or something else, is critical and cannot occur in many industries production environment. Kernel bugs do not always show up in beta, staging or whatever, I have seen several that take MONTHS to occur. Even in modern EL6 kernels. Upgrading willy-nilly without insight into EACH patch applied to the kernel is for the Windows crowd.

Re:Irony

[Anonymous Coward]

false! I never have seen this. I have "check but ask" setting since ages.

Re:Irony

[Arashi256]

I'll bite. The registry *does* get crufty. All sorts of keys from software that you've previously uninstalled. You've clearly not used RegEdit very much searching for software matches that you *know* are no longer there. And Windows (7, SBS, etc) *does* reboot itself automatically when it decides you must. Nobody cares about your respect or lack of it, but simply ignoring the facts that many sysadmins deal with when working with Windows is just stupid.

Re:Irony

[kthreadd]

You do know that 5.8 is out? A simple yum upgrade and it's there.

Re:Irony

[Anonymous Coward]

Same here. Sometimes the update are forced through, and if the machine isn't rebooted, parts of it remains unstable.

Don't be surprised that a reboot fixed your "impossible issue". I suspect Windows Update despite my settings should prevent installing new updates without confirmation.

Of course all the permutations of configurations are impossible to test beforehand, but that's what policy adherency is meant to fix.

Keyword: preempt

Re:Irony

[DarkOx]

Well i think you find out it starts crashing ahead of time in the test environment, and determine why. Then you fix that 'why' and test again. This just is not a valid argument today. Its not 1970 any more. Out side a few really really unusual corner cases if you are operating a computer system that really needs 99.999% up time you either have a test environment or you don't *really* need five nines.

Re:Irony

[techno-vampire]

Not a trick question - but now you're exactly where you were before you tried to fix it..

Yes. You're right back where you started, with only your original, known problem, and without any new problems caused by the update. How easy is it to back out of a bad update on a Windows box if that's what you need? Please understand that this is a serious question, because I've not run Windows at all for at least four or five years, and when I did, I never ran across this situation, so I really don't know the answer.

Re:Irony

[TheTrueScotsman]

I have about 30 Windows server machines (mix of 2003 and 2008) in a a server pool that I inherited. All are set to manual updates and I have never seen an unwanted restart that wasn't due to a hardware problem (some of the machines have been running for over five years). I call bullshit.

Re:Irony

[0123456]

One of our installed systems runs on CentOS 5.1 (on a private network only accessible to a few authorised users via VPN with dual-factor authentication, so we can live with the security issues). If you try to run the software on CentOS 5.8 it crashes on startup because of MySQL changes between the two versions.

So out here in the real world where servers have to run unattended for years with only brief outages, updating the operating system is far from 'a simple yum upgrade'.

Re:Irony

[arth1]

You do know that 5.8 is out? A simple yum upgrade and it's there.

You mean a simple yum upgrade on a staging server, followed by diffing hundreds of .rpmnew/.rpmsave files, followed by restart of the services where those files were changed, followed by regression testing all the business critical software running on the machine, followed by a simple yum upgrade in production, followed by putting in place new config files based on the experience from staging, followed by service restart and/or reboot, followed by monitoring?

Anyone who does "yum upgrade" from EL 5.3 to 5.8 on business systems without any kind of testing or impact analysis is what I would like to refer to as an ex-sysadmin. Some of the changes there do have impact. Not the least in the SElinux area, where relabeling and changing contexts might be required for continued operations.

Re:Irony

[Hognoxious]

I run SAP on mine, and it's notoriously picky & fussy about dependencies. It's not a production machine (just a sandbox, ie. there's no sandsandbox to test on), but people would be inconvenienced if it went wrong. No way would I even consider doing an in-place upgrade.

And anyway, 6.2 has been out long enough that it's moderately stable. But when I do it I'll install the new OS onto a new HD so I can dual boot until things settle.

Re:Irony

[Hognoxious]

Funnily enough I was replying to the parent. *He* didn't mention wussiesussies, did he?

Re:Irony

[Anonymous Coward]

And therein lies part of the problem. Distributions all tend to use a certain version of the kernel and release security patches but no major updates until the next release of the distribution. That keeps the system stabler by using packages with the kernel version they've been tested for and avoids introducing any interface changes that might break some applications that talk to the kernel at a lower level than most. That means for instance that Debian Squeeze is on 2.6.32 and will be until the Wheezy release when it'll move to some version of 3.x. So it's understandable that this fix wouldn't have been backported to 2.6.32 unless it was tagged as a security bug, and most users want to update to a stable kernel version rather than try to install their own custom-build kernel that might cause them other problems.

How is this an issue?

[Anonymous Coward]

NTP says it's 12:34:56pm, then it's 12:34:56pm. Why would a leap second lock things up any more than a clock that's one second slow and is corrected by NTP?

Re:How is this an issue?

[swalve]

When NTP tries to say that it is 12:34:61 and the computer only expects 1-60.

Re:How is this an issue?

[whitedsepdivine]

Today - 24 hrs = Today; Only Today.

Today - ( 24 hrs + 1 sec) = Yesterday

Re:How is this an issue?

[Anonymous Coward]

You mean 0-59 and tonight is 60, right?

Re:How is this an issue?

[at10u8]

Watch the excitement unfold as recent kernel patches unravel http://serverfault.com/questions/403732/anyone-else-experiencing-high-rates-of-linux-server-crashes-today

Re:How is this an issue?

[Anonymous Coward]

When NTP tries to say that it is 12:34:61 and the computer only expects 1-60.

Why wouldn't they just jump from :05 to :07?

Re:How is this an issue?

[mgscheue]

It actually goes 23h 59m 59s, 23h 59m 60s, 00h 00m 00s. See http://www.nist.gov/pml/div688/leapseconds.cfm

Re:How is this an issue?

[msauve]

Poorly written software only expects seconds to go from 0-59. Positive leap seconds are counted 23:59:59 -> 23:59:60 -> 0:0:0. Leap seconds have been around since 1972, the same year Unix was rewritten in C. There's been plenty of time to get things right.

Re:How is this an issue?

[Anonymous Coward]

Depends on the definition of an hour. Does the leap second make one hour slightly longer or does it not belong to an hour. If you add or subtract hours, are they always normal hours or does it depend on the date and time to/from which they are added/subtracted. The computer could treat a subtraction of 24 hours across the leap second as a subtraction of 86401 seconds. If however you subtract 86400 seconds, which is more likely, it couldn't do the right thing.

Natural time is hard, that's why at their core, computers use "(milli/micro)seconds since the epoch" as their primary notion of time.

Re:How is this an issue?

[Anonymous Coward]

I don't buy my cars from car.com, and I don't get my kernels from kernel.org.

I've been running FreeBSD since 1.0, and 386BSD before that. Never had a problem with leap seconds.

Re:How is this an issue?

[bunratty]

Because that would be the opposite of a leap second maybe?

Re:How is this an issue?

[msauve]

That would subtract a second. While that is possible, it's never happened. In any case, leap seconds, added or subtracted, are preferably at midnight on the last day of June or December, second preference last day of March or September. They are, however, allowed to happen on the last day of any month.

"A positive or negative leap-second should be the last second of a UTC month, but first preference should be given to the end of December and June, and second preference to the end of March and September." - ITU-R Recommendation TF.460-4

Re:How is this an issue?

[Anonymous Coward]

For once i feel good for my lazy coding, at least it supports all kinds of leaps (and goto-s). Maybe we should only work on 64-bit unsigned integers to be sure? 64-bit hours, 64-bit minutes, 64-bit seconds?

Re:How is this an issue?

[whitedsepdivine]

The problem is that an hour is a constant length a (TimeSpan), and is considered indepentant from the current time (DateTime).

An hour is equal to 3600 seconds. That is the standard definition of an hour until the last couple decades and not everyone knows that it can actually be 3600s +/- 3s.

So all the code that says this is wrong:
DateTime today = new DateTime(now.Year, now.Month, now.Day); TimeSpan day = new TimeSpan(86400000); DateTime tomorrow = today.add(day);

Re:How is this an issue?

[OneAhead]

Umm... did you realize you're re-posting a link from the summary?

Re:How is this an issue?

[mcavic]

Why would a Unix application ever see the :60? Any time someone checks the clock, the time should be derived from Unix time (seconds since the epoch) which doesn't account for leap seconds. So to an application it should appear as a duplicate :00 or :59.

Re:How is this an issue?

[guruevi]

The problem is not necessary in the time representation, the problem is that when NTP tries to insert the extra second into the kernel, the kernel gets stuck in a spinlock (basically waiting until a lock becomes available which never does).

The thing is that NTP announces this adjustment to the kernel somewhere the day before so it doesn't necessarily happen at 23:59:59 GMT (although it could happen at that time too)

Re:How is this an issue?

[certsoft]

Unfortunately some GPS vendors don't get it right. I was testing conformance of a IT530 from FastRaxGPS which uses the Mediatek MT3339 receiver.

It put out the sequence 23:59:59, 23:59:59, 00:00:00 repeating second 59 instead of using second 60.

Re:How is this an issue?

[Anonymous Coward]

So to an application it should appear as a duplicate :00 or :59.

OK. It's 2012-06-30T23:59:59Z, the moment the leap second is scheduled to happen. You create a "struct tm" object and populate it with this date and time. Then you call mktime(&tm). What is the return value?

The answer is -1. This can be very confusing for programs which, not unreasonably, make the assumption that, for example, :58 plus 1 second = :59. Actually... I don't have access to a Unix box to test this right now, but I suspect that if you choose the epoch time for a leap second and call gmtime(), you'll get a (non-null) struct tm back. But if you then pass that very same struct to mktime() you should get -1. I can imagine that being very non-intuitive under most circumstances.

But even putting aside the stuff I just said, the fact is that computers have to deal with humans, and humans don't think in seconds since the epoch. We say things like "run this task every minute," and the meaning of that statement when leap seconds are involved is unclear. Plus, programmers make lots of assumptions in time_t-land, like that days are 86400 seconds, minutes are 60 seconds, and so on.

Re:How is this an issue?

[__aaltlg1547]

When NTP tries to say that it is 12:34:61 and the computer only expects 1-60.

That will never happen.

Leap seconds are always asserted at UTC midnight on the last day of a month. I think the convention is only to have leap second opportunities at the end of March, June, September and December. Typically, they try to assert it at midnight December 31. It's unusual to have a mid-year leap-second.

Since the normal progression is 23:59:58, 23:59:59, 00:00:00, the extra second makes the time 23:59:60. 61 would be TWO leap seconds which won't happen any time soon. The Earth's rate of rotation would have to change by nearly two seconds in 3 months.

Re:How is this an issue?

[batrick]

$ man date
[...]
                            %S second (00..60)
[...]

Oh, maybe when you use that (or strftime).

Re:How is this an issue?

[__aaltlg1547]

That's because the Earth's average rate of rotation is just a little slower than one solar revolution per day. To cause that to speed up would take a large change in the Earth's moment of inertia. For instance, due to compaction of the Earth's core, cooling of the oceans or formation of massive glaciers at the poles.

Nevertheless, our timekeeping systems are designed to have both positive and negative leap seconds.

Re:How is this an issue?

[__aaltlg1547]

I've seen systems that do that, but if it does that it's not UTC. UTC goes 23:59:58, ,23:59:59, 23:59:60, 00:00:00 when there's a leap second.

Re:How is this an issue?

[ganjadude]

Why havent the clock writers written an exception for the occational 61 yet after all the issues over clocks in the past, y2k etc??

Re:How is this an issue?

[Anonymous Coward]

You just have a bunch of problems with other things, like poor hardware support, poor SMP support, etc.

Re:How is this an issue?

[ganjadude]

this is /. ...you think people RTFA's??

Re:How is this an issue?

[msauve]

"That's because the Earth's average rate of rotation is just a little slower than one solar revolution per day."

You're confusing the need for leap seconds with sidereal time. But note, the Earth actually rotates faster than one solar revolution per day.

Leap seconds are needed because when we changed the definition of a second from 1/86400th of a day to one based on a characteristic of the Caesium atom, a poor value was chosen, and the Earth is slowing down over time, primarily due to tidal acceleration by the moon.

Re:How is this an issue?

[Hognoxious]

What does the chosen value have to do with anything? What, pray tell, should it have been?

Re:How is this an issue?

[hyperfine transition]

You're right.
An application will see two 23:59:59 timestamps (in Linux anyway) because the
clock is stepped back by 1 s during an addition.

In ntp.c second_overflow() it says /*
    * Leap second processing. If in leap-insert state at the end of the
    * day, the system clock is set back one second; if in leap-delete
    * state, the system clock is set ahead one second.
    */
and at the time the leap second goes in
  case TIME_INS:
    if (secs % 86400 == 0) {
          leap = -1;
          time_state = TIME_OOP;
          time_tai++;
          printk(KERN NOTICE "Clock: inserting leap second 23:59:60 UTC\n");
          }
          break;
and in timekeeping.c it says
  leap = second_overflow(timekeeper.xtime.tv_sec);
  timekeeper.xtime.tv_sec += leap;
  timekeeper.wall_to_monotonic.tv_sec -= leap;
where xtime is the "current time"

Re:How is this an issue?

[hyperfine transition]

I was doing leap second testing in the last month and I'm pretty sure that date
returns
23:59:58
23:59:59
23:59:59
00:00:00
as you go through the leap second addition
(Un)fortunately, not at work so I can't double check but a quick look at the date source code suggests that this is indeed
its behaviour on Linux.

Re:How is this an issue?

[Anonymous Coward]

That code is wrong twice a year in any case, since we already have 23-hour days and 25-hour days.

Re:How is this an issue?

[keeboo]

When NTP tries to say that it is 12:34:61 and the computer only expects 1-60.

Why only add a leap second, when you can also add a fixed +1 offset to the seconds while you're at it.

Personally I would rather normalize the minute cycle to a prime number of seconds, but that's just me.

Re:How is this an issue?

[keeboo]

What the heck is the opposite of a leap second?
A leap anti-second?

Re:How is this an issue?

[msauve]

I didn't say an application would see :60. But, it exists in UTC. The problem is that generally, *nix can't handle the truth. So, kernels either step time backwards by a second, or stretch time around a positive leap second. Both cause problems if accurate timekeeping is important.

Re:How is this an issue?

[msauve]

A day is one Earth revolution, relative to Sol. It varies slightly because of a number of factors, and is called UT1. UT2R is a smoothed version, and but variations due to unpredictable events are left. UTC is based on the atomic second. The value chosen for the atomic second is such that, on average, there have been slightly more than 86400 of them in a day. So, just as a year is more than 365 days (a day is slightly shorter than 1/365 year), so an occasional leap day needs to be added, so to an occasional leap second is needed.

Contrary to what the GP said, the solar day is not too fast. It is what it is, by definition. Rather, the second is a bit too short.

On average, since the leap second was introduced in 1972, one has been needed about every 18 months. Over the long term, that rate will increase as tidal acceleration slows the earth. 1 sec/18 months ~= 2e-8, so that's how much the second has been off on average since 1972. The atomic value for the second is 9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium 133 atom. So, a better value might have been 9,192,631,967, which would make us about even to date. (Although, since leap seconds aren't distributed evenly, they would still have occurred, both positive and negative, just not as many.) The original value was based on measurements made over less than 3 years, and has worked for some shorter periods (there were no leap seconds between 1999 and 2004, for example), but the value chosen has proven to be too short over the 40 years of leap seconds.

Re:How is this an issue?

[mcavic]

Thanks - the kernel log on one of my machines seems to indicate that the :59 was repeated. That's what I would hope for the sake of software compatibility.

Re:How is this an issue?

[mcavic]

Yeah, I understand that the :60 exists in the real world. But from a computing standpoint, a small approximation seems to make things much easier.

Re:How is this an issue?

[thogard]

Because of the way the time stored in a time_t works with the time zone libraries is that the time right now is right. The time a month ago has been retroactively shifted a second and the time a decades ago (to the era of t=0 for GPS) has shifted 14 or so seconds.

It all mostly works for most things. There are a few that it doesn't work for and that tends to be limited to scientific fields where they already have ways to taking those things into account or have determined that they don't matter.

This also means that a time_t of 1 341 132 265 doesn't have 10 significant digits.

Re:How is this an issue?

[Anonymous Coward]

great explanation dude !

Re:How is this an issue?

[Anonymous Coward]

Clearly you have no idea what you're writing about.

Re:How is this an issue?

[Smauler]

ok.... why don't they just have _two_ 12:34:60's then?

Thinking about it.... 12:34:60 is the leap second - 12:34:61 would be a second leap second.

So, why don't they have 2 12:34:59's?

Re:How is this an issue?

[Anonymous Coward]

What the heck is the opposite of a leap second?

A leap anti-second?

No, it's an anti-leapsecond you Id10t

captcha: obvious

Re:How is this an issue?

[__aaltlg1547]

"That's because the Earth's average rate of rotation is just a little slower than one solar revolution per day." You're confusing the need for leap seconds with sidereal time. But note, the Earth actually rotates faster than one solar revolution per day. Leap seconds are needed because when we changed the definition of a second from 1/86400th of a day to one based on a characteristic of the Caesium atom, a poor value was chosen, and the Earth is slowing down over time, primarily due to tidal acceleration by the moon.

No I'm not confusing anything. You're confused. Sidereal time is rate of absolute rotation (relative to the "fixed stars"). The day is based on the rate of rotation relative to the SUN. That's called solar time.

If the Earth rotated faster than one solar revolution per day we would have to skip seconds to keep the atomic second count synchronized with the Earth's rotation. We have to (only) add leap seconds because the Earth rotates a smidge slower than one rotation per 86400 atomic seconds.

Over short time scales, such as between 1967 and now, tidal acceleration is not the dominant factor, although it is over much longer periods.

Re:How is this an issue?

[NewYork]

Sleep second?

Re:How is this an issue?

[heypete]

Because that is ambiguous. If something happened at :59.817, do you know which of the two "59" seconds it took place in? No. What if two events happen, one at :59.817 and :59.923 -- which one is first? You don't know if the 59.817 one took place in the first or second 59th second. Bad things can happen if systems have ambiguous time, particularly if time appears to stand still or go backwards.

A better option would be to insert a leap second at one particular minute, wait one minute, then insert a second leap second. Of course, having two leap seconds in such a short period would be unusual.

Re:How is this an issue?

[Hognoxious]

A day is one Earth revolution, relative to Sol.

You mean the sun?

In any case, you're wrong. There's also a sidereal day that has fuck all to do with the closest hydrogen fusing body.

Contrary to what the GP said, the solar day is not too fast. It is what it is, by definition. Rather, the second is a bit too short.

The solar day is neither too fast nor too slow. It's too irregular and has no primary referent.

On the other hand the second is tied to so many physical units that it makes perfect sense to hold it constant. If you don't do that, we'll have to constantly adjust the speed of light every time the third rock from the sun gets a judder. That would affect everything from mass-energy equivalence down.

You want us to do all that so you don't get confused because once in a blue moon a day has a different number of seconds? Bend it into a U shape.

Essentially, the second is a scientific unit, the day is a commercial one.

Take the calendar month. Do you grumble that you're being ripped off on the rent for February? And does your mom point out that you never actually pay anyway?

Re:How is this an issue?

[Anonymous Coward]

Great? In the quantity sense (as in a great weight) then perhaps.

Quality wise it was a bag of cunt.

Re:How is this an issue?

[msauve]

Ho hum.I should have known better than to try to explain it to an idiot.

Re:How is this an issue?

[msauve]

"No I'm not confusing anything. "

That only makes your incorrectness all the more embarrassing.

Re:How is this an issue?

[tconnors]

Why would a Unix application ever see the :60? Any time someone checks the clock, the time should be derived from Unix time (seconds since the epoch) which doesn't account for leap seconds. So to an application it should appear as a duplicate :00 or :59.

localtime(3) tells me that
              tm_sec The number of seconds after the minute, normally in the range
                                  0 to 59, but can be up to 60 to allow for leap seconds.

The problem is that the epoch returned by time(2) defined by POSIX is idiotic:
              POSIX.1 defines seconds since the Epoch as a value to be interpreted as
              the number of seconds between a specified time and the Epoch, according
              to a formula for conversion from UTC equivalent to conversion on the
              naive basis that leap seconds are ignored and all years divisible by 4
              are leap years. This value is not the same as the actual number of
              seconds between the time and the Epoch, because of leap seconds and
              because clocks are not required to be synchronized to a standard referâ
              ence.

The correct thing to do would have been to define time() to return TAI or the like. Monotonic. Calculations involving deltas of time should just be deltas of that epoch value in seconds. Easy. If you find yourself trying to manipulate individual components of datetime stamps for purposes other than display and input, You're Doing Things Wrong. The only thing that would care about seconds being 60 would be the presentation layer. localtime() return tm_sec 60, so display 60. No need to "sanity check" (wrongly) the value returned by system libraries to be between 0 and 59 - they should be written by people smarter than yourself usually and they surely know about leap seconds, right? Right?

But unfortunately, idiocy was encoded into the standards, so further idiocy is required to work around the original idiocy. Before long, the world is being run by idiots. And it becomes even harder to undo the idiocy in higher layers even if you're competent and know what you are doing.

Re:How is this an issue?

[Anonymous Coward]

I think the convention is only to have leap second opportunities at the end of March, June, September and December. Typically, they try to assert it at midnight December 31. It's unusual to have a mid-year leap-second.

The leap second could be added (or subtracted) at the end of any month, but in practice the leap second has only been inserted at the end of December (15x) and June (10x) since June 1972 to ensure that | UTC - UT1 | < 0.9 seconds.

Re:How is this an issue?

[ls671]

You're confusing the need for leap seconds with sidereal time. But note, the Earth actually rotates faster than one solar revolution per day.
 

More precisely, 1 earth rotation takes about 23h56m

http://en.wikipedia.org/wiki/Earth's_rotation#Stellar_and_sidereal_day

Re:How is this an issue?

[mcavic]

POSIX.1 defines seconds since the Epoch as a value to be interpreted as the number of seconds between a specified time and the Epoch, according to a formula for conversion from UTC equivalent to conversion on the naive basis that leap seconds are ignored and all years divisible by 4 are leap years.

I think that's the only way to do it. You need some formula to convert between epoch time and component time, and a static formula can't account for arbitrary leap seconds. For computing purposes, instead of thinking of a leap second as making the day one second longer, think of it as a one-time adjustment to your clock.

Re:How is this an issue?

[OneAhead]

I know, but this is not even TFA, this is TF /. summary, you know, the stuff on top of the page with trolls and flames. ;)

Re:How is this an issue?

[__aaltlg1547]

You're confusing the need for leap seconds with sidereal time. But note, the Earth actually rotates faster than one solar revolution per day.

More precisely, 1 earth rotation takes about 23h56m

http://en.wikipedia.org/wiki/Earth's_rotation#Stellar_and_sidereal_day

That's absolute rotation or sidereal rotation, neither of which defines a day. Nor is a day a fixed number of atomic seconds. A day is one rotation relative to the sun. Jesus, don't they teach ANYTHING in school any more?

Re:How is this an issue?

[__aaltlg1547]

Please notify me when I make an error as ridiculous as your saying

But note, the Earth actually rotates faster than one solar revolution per day.

.

Re:How is this an issue?

[msauve]

Are you deliberately ignoring context (sidereal motion), or do you have a problem with the fact that the Earth revolves around the sun, and therefore rotates at different rates relative to the sun and stars? Most of us have post-Copernican beliefs.

(BTW, you've made a ridiculous error - it's "you're," not "your.")

Re:How is this an issue?

[__aaltlg1547]

As I suspected, English is not your first language. When you get the grammar down, it will be easier to have a discussion without so much confusion on your part.

NO !! NO THEY ARE NOT !!

[Anonymous Coward]

I am okay with it !!

More important than kernel issues

[Anonymous Coward]

For those wondering whether they get one more second of sleep tonight or one less, the rule is 'spring forwards, fall back, summer stand there looking confused'.

Does this affect desktop distros?

[Quantum_Infinity]

Will this affect desktop distros such as Ubuntu? Seems like a few Debian based servers have crashed. http://serverfault.com/questions/403732/anyone-else-experiencing-high-rates-of-linux-server-crashes-today

Re:Does this affect desktop distros?

[Osgeld]

dunno whats ubuntu based off of (debian)

Re:Does this affect desktop distros?

[nzac]

Read the summary. This was fixed it appears in 2.6.29 kernels still used from before this will be old (and ironically considered "stable").
Modern Desktop distro's will be using 3.x which has had had this fixed for a long time. Ubuntu will be using 3.3 i would expect.

The only distros using old kernels will be some versions of Debian, CentOS and some based off it because this is a well tested stable kernel.

Re:Does this affect desktop distros?

[msauve]

You mean the GP linked article, where it is said "This affects RHEL 6 and other distros running newer kernels (newer than approx 2.6.26)"? Or where is says that Debian Stable (Squeeze, kernel 2.6.32) is affected?

Re:Does this affect desktop distros?

[marcosdumay]

Debian stable (sqeeze) is using 3.0, you can take it out of the list. I don't know about old-stable, but if even Debian already upgraded, there isn't probably any important distro using it anymore.

Re:Does this affect desktop distros?

[MichaelSmith]

There shouldn't be any problems with operating systems at all. The only problems I know about are with critical real time systems which use GPS to set the time at both ends of an interface, but which slew the time by different rules.

Re:Does this affect desktop distros?

[nzac]

I expect they patched the kernel at some stage and the only people running the kernel either have not updated in years or know how to apply the workarounds.
Quantum appeared to be concerned if desktop Ubuntu that he was using was at risk of crashing.

Re:Does this affect desktop distros?

[rHBa]

I'm running Ubuntu 10.04 LTS (long term support) Lucid which I keep up-to-date and I'm currently on kernel version 2.6.32 which shouldn't have a problem.

I also have an install of 12.04 (latest LTS) which I'm slowly transitioning to that runs 3.x so if that doesn't work I reckon 2/3 of the internet will fall over...

Re:Does this affect desktop distros?

[Anonymous Coward]

Google's Galaxy Nexus phones seem to be having some sort of GPS problem today. Everyone with a Galaxy Nexus says their GPS is showing them further west than they really are. Sounds like it may be related to this leap second stuff. Interestingly enough, I haven't heard of any other Android devices having this problem though, so who knows...

Re:Does this affect desktop distros?

[philip.paradis]

No, Debian stable (Squeeze) uses 2.6.32. Where are you getting your information? If you're getting it from some random VPS provider, be advised that you're probably not running a native Debian kernel. Also, this bug appears to affect that kernel and others beyond the indicated level, judging by continuous reports coming in throughout the day.

Re:Does this affect desktop distros?

[amRadioHed]

Can't say I've noticed it. And I was using GPS navigation shortly after the leap second, so I think it would have been pretty obvious to me.

Re:Does this affect desktop distros?

[billybob]

Um, no, Debian stable (squeeze) is kernel 2.6.32.

Re:Does this affect desktop distros?

[msauve]

GPS navigation uses GPS time, which doesn't have leap seconds. Leap seconds shouldn't have any effect on GPS navigation. One can also derive UTC from GPS, because both a pending leap second flag and a GPS-UTC offset are provided. The GP was apparently referring to systems which use GPS receivers to derive UTC time.

Re:Does this affect desktop distros?

[dbIII]

Some of us are stuck on older versions of RHEL5 or CentOS because we are running commercial software that has a glacial pace of development.

Re:Does this affect desktop distros?

[Cthefuture]

My up-to-date Arch workstation went haywire (kernel 3.4.4). mysqld, firefox, and ksoftirq were using a massive amount of CPU. Stopping the processes made the CPU usage go away but as soon as I restarted them they would go nuts again. I had to reboot the machine.

I have an Ubuntu 12.04 server and Debian stable server that apparently were not affected. My Linux based routers also seemed unaffected although they don't run ntp as a daemon which probably makes a difference.

Re:Does this affect desktop distros?

[Cthefuture]

Hmmm, I just now noticed that my Ubuntu and Debian systems did not insert the leap second. That's probably why they didn't have problems.

Not sure why they didn't insert it, they're all running ntpd. Now their time is off by one second.

Re:Does this affect desktop distros?

[marcosdumay]

Yep, you are righ. Now I'll have to dicover how the machine that I looked yesterday got the kernel 3.0.

what about the metric time system?

[Joe_Dragon]

what about the metric time system?

Re:what about the metric time system?

[camperdave]

what about the metric time system?

We are using the metric time system. Under Chapter 4 Section 6, days, hours, and minutes are acceptable units using the customary definitions.

Re:what about the metric time system?

[VMSBIGOT]

Are you referring to the table that is titled "Non-SI units accepted for use with the International System of Units"?

Metric Time != Acceptable non-SI units
http://en.wikipedia.org/wiki/Metric_time
"Metric time is the measure of time interval using the metric system, which defines the second as the base unit of time, and multiple and submultiple units formed with metric prefixes, such as kiloseconds and milliseconds. It does not define the time of day, as this is defined by various time scales, which may be based upon the metric definition of the second. Other units of time, the minute, hour, and day, are accepted for use with the modern metric system, but are not part of it."

Now, not disputing that you can use them as a SI-style base, but wasn't the point of SI was easier math? No crazy unit conversions, just move a decimal point around. Diving by 60, 24 and 365 and etc. is ugly and on top of that, things don't exactly line up either. How long do you consider a year (Hint, there are several acceptable lengths of time as an answer)

I guess computers *do* use SI in the aspect that time is generally done in 10ms quantum's, or whatever your particular OS uses.

Re:what about the metric time system?

[camperdave]

I guess it all depends on what the original poster meant by metric time. Everyone measures time in seconds (granted, there is an obscure hindu time scale based on eye blinks, and Swatch has their beat system), thus everyone measures time metrically. However, nobody generally uses the metric prefix scale for super-second time divisions (eg kiloseconds, megasecond) although they are used for sub-second times.

I suspect that the OP was talking about some decimal time system, which won't ever be accepted because it would require redefining the second, and hence redefining practically every physical constant.

Re:what about the metric time system?

[jedwidz]

Another big drawback of decimal time is of course that we'd lose a lot of handy factors.

Imagine a world where everyday utterances like 'meet you at a third to four' or 'let's break for fifth of an hour' would be met with quizzical expressions before everyone fumbles for their calculators.

The leap second is done horribly wrong

[Anonymous Coward]

Leap seconds have no place in Unix time. They make the assumption that time moves forward invalid (a subsequent call to gettimeofday may return a number the previous one), which is the cause of oncountable bugs. Raise your hand if you didn't know this is how it works.

Why don't they put leap second handling in the layer that converts from Unix time to user-visible representations, like timezones, DST and, oh I don't know, leap DAYS?

Re:The leap second is done horribly wrong

[Anonymous Coward]

Meant to say that a subsequent call to gettimeofday may return a number less than the previous one.

Re:The leap second is done horribly wrong

[at10u8]

Perchance something like this example worked with existing deployed and tested code? http://www.ucolick.org/~sla/leapsecs/right+gps.html

Re:The leap second is done horribly wrong

[Electricity Likes Me]

Isn't it always invalid? If the NTP server does a correction between the first call and the second call, then you could still get time not moving forward.

Re:The leap second is done horribly wrong

[Hognoxious]

No, but it might return a number equal to the previous one.

This could happen anyway if you make two calls in an interval less than the granularity of the clock so there's no excuse for not handling it properly.

Re:The leap second is done horribly wrong

[sjames]

It is perfectly valid for two back to back calls to gettimeofday to return the same value. It can happen at any time if the calls are closer together than the granularity of the time.

It is unusual, but perfectly possible for the second result to be less than the first if the clock has been reset. It is bad form for a program to panic over that. However, to try to avoid problems and to make logs a LOT less confusing, NTP prefers to slew the time rather than make hard adjustment. That is, it speeds up or slows down the system clock a bit so that system time and the reference time will converge.

Re:Haha

[93 Escort Wagon]

Enjoy your free operating system that was stopped by an extra second.

Yes, because we've NEVER seen Windows have problems dealing with things like Daylight Savings...

as of about a year ago, I started defensive coding

[GoodNewsJimDotCom]

Hello, Some of us code our systems somewhat like a finite state machine, and we figure our machine will never operate outside it.

If you're testing if something that increments ever hits a number(like 10) and goes back to 0, instead of checking if it ==10, check if it is >9.
There are a lot of defensive coding mechanisms you can use. The downside of this is that when you debug, something can sneak by and put you outside of a state you want, so it makes it ever so slightly harder to debug. But if you're making software that will be used by the public that is hard to give updates, defensive programming can save the day here and there. ,Jim

Leap seconds are an idiotic idea

[Anonymous Coward]

If the ITU never inserted another leap second again, just letting UTC sloooowly diverge from solar time, it would not create any real problem for hundreds of years. And by that time either we'll either have developed the technology to adjust the Earth's rotation itself to correct the discrepancy, or else civilization will have been destroyed by nuclear war/global warming/etc. Either way we wouldn't have to worry about leap seconds.

Re:Leap seconds are an idiotic idea

[mynamestolen]

what's your evidence that it wouldn't be a problem?

Re:Leap seconds are an idiotic idea

[Anonymous Coward]

If the ITU never inserted another leap second again, just letting UTC sloooowly diverge from solar time, it would not create any real problem for hundreds of years. [b]And by that time either we'll either have developed the technology to adjust the Earth's rotation itself to correct the discrepancy,[/b] or else civilization will have been destroyed by nuclear war/global warming/etc. Either way we wouldn't have to worry about leap seconds.

Oh man you're funny.

Re:Leap seconds are an idiotic idea

[at10u8]

The ITU doesn't insert anything, they just emit documents to which everyone is expected to conform, but the ITU-R process does not require consensus, interoperability testing, nor even a description of implementation details. All of that are Somebody Else's Problems.

Re:Leap seconds are an idiotic idea

[Anonymous Coward]

You'll want to look up this funny thing called "Atomic Time".
 
You're welcome to it, but we really shouldn't be changing UTC to duplicate TAI. If you want others to join you, get the world to switch from UTC to TIA.

Re:Leap seconds are an idiotic idea

[Anonymous Coward]

Assuming an average of one leap second per year, it would take 300 years to accumulate just a measly 5 minutes of difference. Compare this to what we already have due to time zones: Since time zones are generally discretized to one hour, there will always be places which are already off from solar time by up to +/- 30 minutes. In fact, since time zone boundaries aren't perfectly lined up with meridians, there are places where it's off by even more than that. Moreover, daylight saving time throws things off by a whole hour. And somehow, life goes on. There is just no need for civil time to be synchronized with the sun all that precisely.

Re:Leap seconds are an idiotic idea

[msauve]

UTC is defined to be linked to Sol. It is used for things which depend on that characteristic (like astronomy and celestial navigation). If civil time doesn't need to be linked that closely, then it doesn't need to use UTC.

Re:Leap seconds are an idiotic idea

[John Hasler]

> ...it would not create any real problem for hundreds of years.

It need not ever create any problems. Put the leapseconds in zoneinfo. There is no more reason to jigger the system clock to deal with the fact that the planet's rate of rotation varies than there is to jigger it to deal with the fact that the sun rises at different times at different longitudes.

Re:Leap seconds are an idiotic idea

[MichaelSmith]

For a start we all live in kludged up timezones anyway. I could be as much as an hour from "the correct solar time". People in China could be three hours from that time, because they have fewer timezones.

Re:Leap seconds are an idiotic idea

[camperdave]

If they're worried about millisecond differences in stock trading, I suppose fortunes will be gained and lost over this extra second.

Re:Leap seconds are an idiotic idea

[camperdave]

Exactly. And this is why we have time zones in the first place; for most things, it is far better to be synched to each other than the local solar time.

Re:Leap seconds are an idiotic idea

[techno-vampire]

Put the leapseconds in zoneinfo.

That would work just fine if leap seconds occured at regular, predictable intervals the way leap days do, but they don't. AFAIK, there's no way to know in advance when it's going to be appropriate to have one, so there's nothing that can be put into zoneinfo to deal with them.

If we were a space-based civilization, living in ships, space colonies and bases on moons, asteroids and so forth, there'd be no reason for leap seconds but we're not. As long as we're stuck on this planet, it's going to be convenient to keep our time keeping synchronized with the Earth's rotation as closely as we can, and doing that requires the occasional leap second.

Re:Leap seconds are an idiotic idea

[hyperfine transition]

"Assuming an average of one leap second per year, it would take 300 years to accumulate just a measly 5 minutes of difference." It's a bit faster than this because the tidal slowing of the earth;s rotation increases the discrepancy by about 1 ms per day per century (ie after 100 years, the average day is 1 ms longer, so you get an extra leap second every 3 years. And after 200 years, an extra leap second every 18 months and so on).

Re:Leap seconds are an idiotic idea

[Anonymous Coward]

The US stock market is always closed when leap seconds happen. So are the European stock markets.

Re:Leap seconds are an idiotic idea

[UnknownSoldier]

Completely agree!

Hey guys, I know, let's OVER ENGINEER _time_! WTF!?

Stop it already with these stupid bullshit hacks of leap seconds, daylight savings time, etc. They cause MORE problems then they SOLVE.

Re:Leap seconds are an idiotic idea

[Anonymous Coward]

Sorry, but you are mistaken. Leap seconds are planned for well in advance by the UTC timekeeping authority. They set the date when leap second occur just like the civil authorities set the date for their DST switch-over and switch-back to Standard Time. You need to update your timezone file at least once a year as it is; just update it often enough to catch the planned-for leap seconds and you are done. (If it bothers you to put them in zoneinfo, create a new file just for leap seconds.) You need to record when all leap seconds occurred anyway in order to create a proper UTC time from the system clock (seconds since Jan 1, 1970).

Re:as of about a year ago, I started defensive cod

[JustNiz]

Our servers run on octal, you insensitive clod.

Better safe than sorry

[Anonymous Coward]

At my shop, we did a dry run a couple of weeks ago. Things went very well and we had no issues. That said, I still unplugged the time server from the network this weekend, just in case. I really don't want to get a call from one of the far flung server admins, telling me something went wrong. The risk of issues caused by losing a few seconds across the network is much less than the potential damage from even one server doing the wrong thing.

Now you tell us.

[portablejim]

Being UTC+10 means that I read this story and get excited about watching the leap second, only to discover it happened last night. I guess because I didn't notice means that I was ready.

Re:Now you tell us.

[Anonymous Coward]

Being UTC+10 means that I read this story and get excited about watching the leap second, only to discover it happened last night.

I guess because I didn't notice means that I was ready.

Ummmmm...no.

The change takes effect at 00:00 UTC, which would be 10:00 for you.

For me, being UTC-8 it would occur at 16:00PST, or 17:00PDT (which just happened while I was typing this!).

Nothing has crashed here...Fedora 16, Ubuntu 12.04, Windows 7.

Re:Now you tell us.

[spazekaat]

Uuugh...forgot to log in first, the above was my comment,

Credit is due where credit is due. ;-)

Re:Now you tell us.

[msauve]

Leap second happens at midnight UTC, not at midnight local time. You posted about 8 minutes before the leap second occurred. I'm guessing you still missed it, though.

Re:Now you tell us.

[portablejim]

*groan*

How stupid of me.

The occasion that I comment about missing something due to being several hours ahead is one of the few occasions where it does not matter.

Re:Haha

[EdIII]

Yeah it had the wrong time but did not freeze up. What's your excuse?

You're really trying that hard to troll huh?

A free operating system has a bug in it so you want to exaggerate the existence of the bug to show that free operating systems are inferior in such a condescending and acerbic way.

I guess that can work. It's not like there is any paid OS out there that has decades long histories of serious instability, security flaws, and badly implemented ideas...... so yeah, you're completely safe making such an arrogant argument.

Re:Haha

[drinkypoo]

Windows: 95. Scene: LAN party. Game: Descent. Hilarity: All the Windows users cursing loudly as their computers spontaneously reboot for DST. DOS users get to feel smug for a change.

Windows has been boning DST as long as Windows has handled your RTC.

out of a state you want

[QuasiSteve]

The downside of this is that when you debug, something can sneak by and put you outside of a state you want

Oh I do hate when that happens at work. We end up so bewildered. "Are we dead? Or is this Ohio?"

( cookies for whoever gets the reference without Googling. )

Re:out of a state you want

[JWSmythe]

Most of us are too old to still watch children's cartoons.

Re:out of a state you want

[QuasiSteve]

But just old enough to still remember them and collect that cookie, I see? :)

( Too many here are too young to even know the cartoons. )

Re:out of a state you want

[zippthorne]

But we're not too old for cookies.

obligatory xkcd

Re:out of a state you want

[Anonymous Coward]

The only things on TV I watch are My Little Pony and Phineas and Ferb.

Re:out of a state you want

[JWSmythe]

I cannot confirm, nor deny, any recollection of the creatures in question. :)

Re:out of a state you want

[cratermoon]

Is this John Wayne? Is this me?

Re:Haha

[93 Escort Wagon]

When daylight savings got shifted to the current longer format - which was within this past decade, mind you - millions of Outlook users discovered that many of their already-existing appointments were shifted by one hour. And, unless you knew when the appointment was created, you had no way of knowing the reported time was correct, or if it was off by an hour.

People had to deal with this for three bloody weeks, until the calendar ticked over to the "old" daylight savings start date. That's a bit more hassle than rebooting a Unix machine ever was.

Re:Haha

[Anonymous Coward]

"I have no sense of humor and will butthurt for Linux." - EdIII (1114411)

Re:Haha

[alexborges]

Windows Azure is DOWN AS WE SPEAK: http://blogs.msdn.com/b/windowsazure/archive/2012/03/01/windows-azure-service-disruption-update.aspx ... congrats on paying for your non working OS without any indemnity either.

Goddamned Java

[Anonymous Coward]

All my Java processes peg the CPU since the leap second, even if I restart them. Maybe a reboot will help...

Re:Goddamned Java

[Anonymous Coward]

All my Java processes peg the CPU since the leap second, even if I restart them. Maybe a reboot will help...

So just like before, then?

Re:Goddamned Java

[Anonymous Coward]

Normally java is just in "waste memory" mode. Now it's "waste memory AND CPU".

Re:Haha

[msauve]

"Windows Azure is DOWN AS WE SPEAK"

What OS are you running, which thinks it's February 29, AS WE SPEAK?

Leap second got Reddit?

[daff2k]

Looks like Reddit's systems weren't ready for the leap second. It been down since around midnight (UTC). You'd think a site as big as that would be ready for such an event.

Re:Leap second got Reddit?

[antdude]

I noticed Reddit had problems with my submissions, my liked feeds since last night. When did leap supposed to start? Last night?

Re:Leap second got Reddit?

[MichaelSmith]

No I think it was okay for half an hour or so after 0000. Slashdot can make a profit for the next couple of hours anyway.

Re:Leap second got Reddit?

[smasch]

Yup, Reddit got nailed.
Here's the tweet on @redditstatus. According to them "We are having some Java/Cassandra issues related to the leap second at 5pm PST."

Re:Leap second got Reddit?

[Ingenium13]

Nope, it went down right at 0000 for me. Interestingly, Chrome 20 on Ubuntu 12.04 x86_64 went to a crawl immediately at 0000 and was using 100% CPU (mostly Flash, but I killed that and other processes would just increase their load). It seemed to cycle through the Chrome processes, with each taking a turn of 20-40% CPU usage. It was during this time I tried to load Reddit and got the page saying they were down. Force killed Chrome, re-opened it, same issue. Tried 2 more times with kill -9 and it kept happening as soon as Chrome opened. I had to reboot to make it stop doing this.

Re:Leap second got Reddit?

[painandgreed]

Looks like Reddit's systems weren't ready for the leap second. It been down since around midnight (UTC). You'd think a site as big as that would be ready for such an event.

Have you tried truing it off and turning it on again?

Re:Leap second got Reddit?

[Anonymous Coward]

Have you tried truing it off and turning it on again?

They probably tried turning it off and turning it on again. And that of course didn't help. A shame you weren't there to explain them that they were doing it all wrong, and that they should be truing it off, not turning it off.

Re:Leap second got Reddit?

[Lothsahn]

Three times?

http://www.thewebsiteisdown.com/

Re:Haha

[Anonymous Coward]

...The difference is that Slashdot and it's users have spent the last decade crucifying Windows for things like that while exalting Linux as superior.

Applications with issues?

[Anonymous Coward]

My server inserted the leap second around 90 minutes ago. Google Chrome 20.x, MySQL 5.5, and MythTV 0.25 on systems NTP synced to the server all did strange and wonderful things simultaneously. Yes, every system was completely up to date.

Anyone care to make this priceless moment from dmesg into a MC commercial?
Clock: inserting leap second 23:59:60 UTC
chrome[19727]: segfault at 0 ip (null) sp 00007fff32ef9b88 error 14
chrome[31567]: segfault at 27a00000000 ip 0000027a00000000 sp 00007fff32ef9b78 error 14

Re:Applications with issues?

[Bitsy Boffin]

Also saw mysql go bonkers on two systems, both Ubuntu 12.04, one server, one desktop. Used 100% of a core. Restarting mysql didn't help but rebooting fixed it.

I saw 100% spikes on other servers at the time, but they sorted themselves out.

Apparantly Mozilla saw it also with MySQL and Java.
http://blog.mozilla.org/it/2012/06/30/mysql-and-the-leap-second-high-cpu-and-the-fix/

Perhaps it's just me

[Anonymous Coward]

that thinks this whole thing is stupid... Go back a second by making one of the minutes have 61 seconds? WTF kind of solution is that? Why TF don't they just go 57...58...59...59...00. Or just stop the clock 57...58...5900

Don't even get me started on "Oh it's best to do it at midnight, in June or August". What what WHAT???? It's a fucking second! A second! Do it any time! Who decided "midnight" was best? Midnight GMT is fucking "wake up and go to work" in Australia and the middle of the afternoon in California - WHOSE midnight is supposed to be the best time to do it...

Fuck me, we have leap years with +1 extra days, we have +/-1 leap hours (DST, BST, whatever you want to call it), and we cope - yet these people are befuddled by a leap second.

Get a fucking grip...

Re:Perhaps it's just me

[UnknownSoldier]

voice = "Seinfeld George": What, you didn't get the memo? We OVER ENGINEER _everything_ including accounting for time in the 21st century baby! :-)

P.S.
Yes, completely agree leap seconds, leap hours, and daylight savings time cause MORE PROBLEMS then what they SOLVE. One of these days we'll outgrow this stupidity ...

Terminology?

[Anonymous Coward]

If 2012 is a leap year, doesn't that make 2012-06-30 23:59 a leap minute?

Re:Terminology?

[dotgain]

It shouldn't in my opinion: if the 'leap' cascades to 'minute', why shouldn't it to hour, day, and so on. Every year with a leap second would be considered a 'leap year'. Bzzt.

Re:Terminology?

[Anonymous Coward]

2012-06-30 23:59:59
2012-06-30 23:59:60 (leap second)
2012-07-01 00:00:00

A leap year has an extra day... so a leap minute has an extra second... hmmm...?

It is the particular (half) year which either has or has no modification. Any combination of 29 February (or not), 59, 60, or 61 seconds 30 June and/or 31 December. So any given year can have 18 intercalary variations:
(29 days in Feb, 59 seconds end of June, 59 seconds end of December) (29, 59, 60) (29, 59, 61) (29, 60, 59) (29, 60, 60) (29, 60, 61) (29, 61, 59) (29, 61, 60) (29, 61, 61) (28, 59, 59) (28, 59, 60) (28, 59, 61) (28, 60, 59) (28, 60, 60) (28, 60, 61) (28, 61, 59) (28, 61, 60) (28, 61, 61)

Re:Haha

[alexborges]

Try and buy an app from your iphone NOW.

Yes!

[antdude]

https://twitter.com/redditstatus/status/219244389044731904 just said so -- "We are having some Java/Cassandra issues related to the leap second at 5pm PST. We're working as quickly as we can to restore service." :D

Re:Yes!

[Anonymous Coward]

We were experiencing cassandra issues as well. Nodes were marking each other as being dead...

Re:Haha

[LurkerXXX]

Congrats on your epic reading comprehension/what-day-is-today fail.

Re:Haha

[Anonymous Coward]

Finally Windows users have something to feel smug over! Maybe in another decade you'll have a second!

Re:Haha

[alexborges]

wrong blog post, but it is down. The apple appstore runs on it and it doesnt work.

ntpd doesn't keep accurate time anyway...

[pongo000]

...at least not on any of my servers, so what's a leap second between friends?

Re:ntpd doesn't keep accurate time anyway...

[Anonymous Coward]

NTP won't fix a grossly inaccurate clock. All it does is slowly skew the time, so if your clock is significantly off it could take days or even weeks to correct itself. You're supposed to call something like ntpdate when the system boots, so that the time is accurate enough that NTP can keep it in sync.

From the documentation:

The maximum slew rate possible is limited to 500 parts-per-million (PPM) as a consequence of the correctness principles on which the NTP protocol and algorithm design are based. As a result, the local clock can take a long time to converge to an acceptable offset, about 2,000 s for each second the clock is outside the acceptable range. During this interval the local clock will not be consistent with any other network clock and the system cannot be used for distributed applications that require correctly synchronized network time.

Re:ntpd doesn't keep accurate time anyway...

[heypete]

NTP certainly can step the clock rather than slew it, but this is not recommended.

If NTP can't keep a reasonably-thermally-stable system in sync, it's almost certainly because that system is broken in some horrible way.

Re:Haha

[LurkerXXX]

Yes, and Netflix was out for a lot of folks yesterday and today even though alot of folks pay for it, because of massive power outages due to storms. Are you going to bitch about that too because, "OMG, an Internet service went down!"

What's that got to due with a bug in an OS? Your story comprehension is as good as your reading comprehension.

4chan too

[cfsharp]

Looks like 4chan was affected by the leap second too. https://twitter.com/#!/4chan

Re:Haha

[Anonymous Coward]

shut up bitch

fedora 13 w/ kernel 2.6.34.9-69.fc13.x86_64

[Anonymous Coward]

After leap second, all programs doing pthread_cond_timedwait() were turned into busy wait loops (google chrome, mozilla thunderbird, others). Restarting programs didn't help.

Re:Haha

[cawpin]

Actually, nothing has ever had a problem with Daylight Savings Time. Many systems are, however, affected by Daylight Saving Time.

looks like it hit reddit

[ffflala]

They've been "Down for Emergency Maintenance" for quite some time now.

One would think they'd have seen this coming, because I'm pretty sure there's a /r/leapsecond subreddit that covers this.

Confirmed...

[deesine]

West by about 800'

Re:Confirmed...

[BitZtream]

Seems unlikely to me that it would be 800 feet off for a 1 second error. 1 light second is considerably further even if the sat was on your visual horizon, which is probably not the sats you are using as they'd have the weakest signal as well. The closer you get to overhead the more the second error would effect you.

Not so great this year either

[Anonymous Coward]

http://lkml.indiana.edu/hypermail/linux/kernel/1206.3/03186.html

GPS Time

[jasnw]

This is also an issue for software that works with GPS data and time. The GPS clocks do not "speeka da leapsecond" so the software needs to keep track of things. There was a 15 second offset, and now it's 16 seconds. This has happened often enough that most areas where this might have been a problem have been discovered, but as slashdotters know, there's new code written every second (even leap seconds), and it ain't all finest kind.

Having issues with java/systems? try this

[mwhahaha]

/etc/init.d/ntpd stop; date; date `date +"%m%d%H%M%C%y.%S"`; date;

Fixed the issues I was having. Credit goes to https://twitter.com/SilvioSantoZ/status/219250677522767872. I didn't have to restart anything after running it. YMMV

Re:Having issues with java/systems? try this

[cratermoon]

That's a fix? Other than shutting down ntp, what does it do? date `date +"%m%d%H%M%C%y.%S"` is pretty much a no-op.

Re:Having issues with java/systems? try this

[jmintha]

I assume it forces setting of the time (to the current time) which resets something. I can confirm it worked for me. Java processes were pegged at 100%, restarting the processes didn't help, but after doing the above, and restarting the java, they were normal again.

Re:Having issues with java/systems? try this

[sjames]

Wouldn't setting the date/time to the current date/time clear the pending leap second flag?

Re:Having issues with java/systems? try this

[Anonymous Coward]

> date `date +"%m%d%H%M%C%y.%S"` is pretty much a no-op.

Nope, it's the actual fix. Stopping/restarting ntpd is unneccessary.

That date command triggers a call to clock_settime() which fixes the problem.

Re:Having issues with java/systems? try this

[tqk]

That's a fix? Other than shutting down ntp, what does it do? date `date +"%m%d%H%M%C%y.%S"` is pretty much a no-op.

Unless we're missing something, I agree. "date -s ..." might do something useful, but that command just displays current date.

Re:Having issues with java/systems? try this

[Anonymous Coward]

All of our SLES 11 SP1 boxes running java were affected. Strangely no SLES 10 or SLES 9 servers were affected. We run a mixture of IBM WebSphere apps as well as Novell Zenworks Management Daemon (all java).

We found just setting the date to the current date as below was enough to get the java processes past the fail condition. stop/starting ntpd has no effect.

        date `date +"%m%d%H%M%C%y.%S"`

Thanks for the tip!

Re:Having issues with java/systems? try this

[cratermoon]

Ah hah, and clock_settime() will get the kernel's attention to clear the deadlock.

Re:Having issues with java/systems? try this

[cratermoon]

Calling date with a time will set the clock, but the string given must match the expect format. Using -s just allows for a more free-form time/date string.

Alleged issue did not appear...

[Urban Garlic]

So the comments are confusing to me as to whether Debian "squeeze" is supposed to have a problem or not, but I have about fifty of these systems running, and as far as I can tell, they're all fine.

I got a whole bunch of these in the logs:
> Jun 30 19:59:59 kernel: [timestamp] Clock: inserting leap second 23:59:60 UTC

I have three of the machines configured as NTP peers to each other, and looking at a few tier-1 time servers. The rest of the machines all use the three local peers as time servers.

My Debian desktop systems at home also seem to be fine.

Re:Alleged issue did not appear...

[jmintha]

I run quite a number of Debian systems, mostly squeeze, but a couple of older releases. None of the machines had any direct problems, however one machine that runs some java processes had the java processes using up 100% of the cpu. Another iscsi server process was filling up the logs with "failed to read from timerfd, Resource temporarily unavailable". And my desktop Debian machine had Google chrome using all the cpu.

The above fix: /etc/init.d/ntpd stop; date; date `date +"%m%d%H%M%C%y.%S"`; date; fixed the problem in all cases.

Re:Alleged issue did not appear...

[Fryth]

I manage a network of a few hundred or so CentOS 4 and 5 as well as Debian Etch and Lenny machines. I'm on call this weekend and my phone is quiet. Seems like this issue really didn't impact everyone. This looks to be a non-issue for me, anyway. I see this too:

Jun 30 19:59:59 kernel: [timestamp] Clock: inserting leap second 23:59:60 UTC

Re:as of about a year ago, I started defensive cod

[Anonymous Coward]

Better yet, check if it is >= 10.

Not knowing your clocks is the root of all evil

[Anonymous Coward]

POSIX has several clocks. The issue here, is that as usual programmers are mostly code monkeys that know little of the insides of whatever their shit will run on. They don't know jack shit about the OS, they don't even know the libc and the C standard well, let alone the hardware. Wimps. Let's not go into the programmers that kid themselves by hiding behind "high level" stuff, which could only work if a very competent team of proper engineers was behind that "high level stuff", which is almost never the case.

POSIX has something called the MONOTONIC clock (which as you can well guess from the name, never does anything surprising, and it is the ONLY clock you should ever use to compute time deltas). But most people out there will use the wall clock, i.e. something that ends up being equivalent to gettimeofday() instead of something that maps to clock_gettime(CLOCK_MONOTONIC). Which is idiotic at best.

That still won't save you from the kernel going bonkers when it has to process a leap second, or sudden outbreaks of imbecility in an otherwise sane land (some of the futex userspace libraries, which _are_ written by people that DO know their shit, still managed to get leap seconds wrong!).

Re:Not knowing your clocks is the root of all evil

[hyperfine transition]

The wall clock time is still useable if you also use adjtimex() (on Linux anyway) to check whether or not there is a leap second in progress. If you want to compute a delta for some event external to your application like a file update then you're going to have to use wall clock time. And you're also going to need a table of historical leap seconds if the event was a really long time ago.

Re:Haha

[ganjadude]

such a low UID and still trolling.... theres something to be said there

Re:Haha

[ganjadude]

unless it gets lept ;)

Exede satellite internet

[Altanar]

My Exede satellite internet service was out from 8:00 EDT to 9:50 EDT... I have no way to verify it was caused by the leap second, but it seems a little coincidental.

Difference is Astronomers going postal on you

[billstewart]

There's a reason for leap seconds, and Astronomers will go postal on you if you try to make your clocks too dumb so they no longer track the stars. If you can't implement leap seconds out of respect, do it out of fear, okay?

Re:Difference is Astronomers going postal on you

[Neil Boekend]

And then we'll find out whether the Hubble is a well disguised orbital cannon.

Re:Haha

[Anonymous Coward]

Windows: 95. Scene: LAN party. Game: Descent. Hilarity: All the Windows users cursing loudly as their computers spontaneously reboot for DST. DOS users get to feel smug for a change.

Windows has been boning DST as long as Windows has handled your RTC.

If Win95 automatically rebooted after becoming completely unusable that would have been a "feature".

Seriously, folks would have paid money to have it skip the BSOD and just reboot and startup some programs that were running before.

NTP server vs. NTP client, Unix Kernel, Unix Apps

[billstewart]

There are different layers where you can run into problems. One of them is the ASCII value a time server hands a a time client - if it's 23h 59m 60s and the client chokes, that's a client problem. If the client tries to set an ASCII clock in the kernel to 23h 59m 60s, and the kernel chokes, that's a kernel bug. If a Unix application library can't cope with the interesting values, that's a library problem.

One obvious workaround is for the NTP server to never answer 23h 59m 60s, and for NTP clients to never tell the Unix kernel that that's what time it is. The way you implement this is simply to detect that it's about to be a leap second and Don't Respond until after it's over. (If your client can't cope with not getting a response from the server, the client's broken anyway.)

On the other hand, if the Unix kernel can't cope with a timeclock being set to 23h 59m 60s, that's a bug that should have been fixed years ago - it's not like leap seconds are a new thing.

Re:Haha

[BitZtream]

It was also fixed by applying a patch that did not require a reboot. So the only hassle was ignorance and not knowing that a simple patch available from MS would fix the problem.

Your example is only 'more hassle' because you don't know what you're doing and instead of taking the normal sane route, you just bitch about it.

Ironically, you talk about patching Linux and rebooting but entirely ignore doing the same on a windows machine. Do your desktops need 24x7 uptime and your servers don't or something?

Re:Haha

[BitZtream]

wrong blog post, but it is down. The apple appstore runs on it and it doesnt work.

Bwahhahhaha

Did you seriously just claim the Apple app store runs on Azure? Are you fucking retarded?

Perhaps you mean Amazon.

Re:as of about a year ago, I started defensive cod

[phantomfive]

And in addition, if you are dealing with time, you MUST prepare for the case where the clock moves around randomly, both forward and backward. Because if your code runs for a long time, it will.

What it sounds like on WWV

[spaceyhackerlady]

I listened to the leap second on WWV. It sounded like this:

tick (23:59:55)
tick (23:59:56)
tick (23:59:57)
tick (23:59:58)
(nothing) (23:59:59)
(nothing) (23:59:60)
BEEP (00:00:00)

It always sounds to me like WWV has gotten stuck or something.

...laura

Re:What it sounds like on WWV

[ColdWetDog]

I listened to the leap second on WWV. It sounded like this:

Sorry about your social life, but that's the most geeky activity I've ever heard of....

The explanation, deadlock...do kill the messenger

[Tmack]

Described here (w/dump): https://lkml.org/lkml/2009/1/2/373

Simple version:
"dont kill the messenger" except when the messenger is going to kill you. Its printk sending notice that the leap second happened that deadlocks against the timer doing the leap second (both vying for xtime_lock). Call it a "feature" of the NTP code. Hence the "turn off NTPD" workaround, if NTP doesnt get notified it should implement the leap second from somewhere upstream, it wont notify about it to the kernel, and the printk shouldnt happen.

-T

Android

[x3CDA84B]

Hey, Sergey Brin: maybe you should take this as a reminder that it sure would be nice if Android devices actually took leap-seconds into account instead of setting themselves to GPS time. My phone now thinks it's 16 seconds in the future compared to every sane electronic system. Sooner or later, that's going to cause problems for certain types of encryption.

Re:Android

[at10u8]

anything that runs its kernel on GPS time can give correct UTC time by following this prescription http://www.ucolick.org/~sla/leapsecs/right+gps.html

How you can fix it if your system tweaks out:

[Anonymous Coward]

date --set `date | awk '{print $4}'`

Openfire started looping - not sure it's related

[Bruce Perens]

Immedately after the leap second, Monit reported that my system had high CPU load. I found that Openfire, the XMPP chat server, was looping, and continues to loop if halted and restarted.

I can't say if this is just a coincidence or connected with the leap-second, just yet.

Bruce

Debian Lenny is EOL

[Anonymous Coward]

Has been for quite some time already. This is ancient stuff. Now routers on the other hand...

Puppet at 100% CPU

[bill_mcgonigle]

The timing was coincident with localtime leap-second, anyway (system clock is UTC). After rebooting the machine things look fine.

In the summer and winter always leap back

[Anonymous Coward]

All leap seconds are "back", i.e. one more second in the day. This is because the earth's rotation is slowing down (mostly due to tidal friction). When they defined the SI second in terms of atomic vibrations they used an average of day lengths over several centuries. But that meant that it was "wrong" from the moment they set it in 1961. The actual solar day was already longer than 86400 SI seconds by 1-2ms and keeps getting longer by 1.7ms per century.

WTF is the issue?

[AliasMarlowe]

Perhaps this is just affecting some kernel versions or specific applications which behave poorly.

One data point: both of my servers were running all night, with NTP updates, and did not appear to have any issues. Both are still running right now, several hours after the leap second. They're Synology boxes running their own version of Linux (DSM 3.1-1636 and DSM 4.0-2196). FWIW, the box running DSM 3.1 has never had a problem with leap seconds, and has endured several since we've had it running almost continuously[*] since 2007. Our desktop systems were not running because everyone was in bed, but those that have been used this morning were fine (Xubuntu 12.04, both the i386 and amd64 flavors).

[*] Since late 2007, it has been rebooted a few times for updates to the DSM system, once for upgrading its internal disks, and has been taken down several times when the length of a power outage exceeded 10 minutes, as our pathetic UPS will only keep the servers running for about 30 minutes. We're in a rural area, so the power is quite dodgy, especially in summer thunderstorms.

Re:WTF is the issue?

[TheRaven64]

The issue is that a lot of software was written on the assumption that there are 60 seconds in a minute. If something happens at the 61st second of a minute, stuff gets confused. Either it rejects the event, or incorrectly marks the time. Leap seconds are an incredibly expensive idiocy designed to make a few astronomers happy.

Re:WTF is the issue?

[romiz]

Given that UTC dates from 1961, and that the leap second concept comes from this, it rather means that a lot of coders are dealing with time without being careful, rather than a fault from the astronomers, who mostly use TAI (without the leap seconds) anyway.

Leap years, daylight saving time, local calendars, all those are also complex issues that need to be taken into account when writing software that needs to correctly handle time. And this is before taking into account the issues brought by the hardware, as clock drift, RTC limitations and integer wraparound, that need to be addressed by the OS developers.

All this means that when it comes to time, most developers should leave it to the OS and language libraries. And those implementing these libraries should take their work seriously, because time is a complex matter, as Y2K and the current issue remind us.

Re:WTF is the issue?

[camperslo]

Well it could be worse, we could have done away with leap year and leap second by changing the definition of a second. While we're at it, a few other things can be changed. Maybe those silly smaller containers of ice cream at the drug store can redefine the half-gallon?

We could have two time scales, a working reality-distortion-field warped time, and time with seconds of traditional length, but no leaps. It would be a bit like magnetic north and true north.

Traditional time would be used for anything where the physics matters. Warped time would be adjusted for our convenience, and syncing days, seasons etc. When there's a large shockwave from the field-forces of a coronal mass ejection that doesn't hit the Earth square-on, warped time can be adjusted for the small changes in rotational speed.

A third time scale will be available to those who need to adjust the age of the Earth to match their religious texts. But they'll be required to use it consistently and will pay a high price as earning an hours' wage will seem to take forever.

I wonder how many OSes support a correction factor to compensate for slightly off-frequency clock oscillators? If some of those systems didn't bother with leap second and just jumped time on syncing with a server, could that result in a jump in the correction factor that'll require some time to renormalize?
That does suggest another way of jumping a second. Change the cock oscillator or correction factor for one day such that the error introduced gives the one second difference.

Re:WTF is the issue?

[petermgreen]

Given that UTC dates from 1961

UTC may date back that far but the present form with leap seconds didn't come until 1972 and I suspect it was some time after that before it was realised it was going to be a permanent arrangement.

And those implementing these libraries should take their work seriously

The problem with any convesion libraries is that if the format you are converting to can't represent what you are trying to convert it is simply not possible to convert without information loss. In particular there is simply no way to represent 23:59:60 in standard unix time becaue the assumption that there are 86400 seconds in a day is baked into the design of the format. Formats with seperate fields can in theory represent that time but whether application code written by people unaware that leap seconds exist (or aware that they exist but also aware that their OS doesn't support them) will handle it sanely is anyone's guess.

The "correct" fix is probablly to have two time APIs, a "legacy" API that continues to fudge things to support legacy time formats (unix time and HH:MM:SS with field ranges limited to 0-59) like computers do today and a "new" API that properly understands leap seconds and assumes the application's it is talking to do the same but even if the OS implements such a thing convincing people to care enough to move to the new API is likely to be very difficult.

Re:WTF is the issue?

[Anonymous Coward]

The issue is that a lot of software was written on the assumption that there are 60 seconds in a minute. If something happens at the 61st second of a minute, stuff gets confused.

It's also an issue for software that requires linear time. The POSIX implementation is not linear. You can't subtract to times and get an accurate time difference due to leap seconds. Programming around this problem can be very very hard.

Re:WTF is the issue?

[Anonymous Coward]

That does suggest another way of jumping a second. Change the cock oscillator or correction factor for one day such that the error introduced gives the one second difference.

Hey! Keep your hands off my cock oscillator!

Re:as of about a year ago, I started defensive cod

[Anonymous Coward]

Some of us work with low budget, crap management, and tight deadlines. Sometimes you just give the code and don't give a shit. Unfortunately.

Re:Haha

[laejoh]

And do remember bitchecker who can not possibly have ping timeouts because he even has dst!

Guess it was fine?

[Anonymous Coward]

After setting up NTP on Linux systems, I forget abou it. Completely. They are all working fine.

OTOH, I check the time on a Win7 TV recording box weekly, just to ensure it hasn't drifted 20 minutes. I'm serious - it used to drift over an hour. I ended up setting up an internal NTP server (on Linux), then forcing Win7, Vista, XP machines to sync with it every 15 minutes. I tried 1 hour and it was still drifting 5+ minutes. I've seen this problem with Windows since 1997 and it hasn't gotten better. The exact same PCs deal with time perfectly when running Linux. Odd?

Back when I was in corporate IT with about 5 onsite Microsoft engineers assigned to the company (we had over 120K desktops), they told me that desktop clocks within 5 minutes was acceptable. I'm 100% serious. I could tell when the PC was off - the time on the phone would be correct, set by a UNIX NTP box "somewhere", but I'd be late to meetings because my PC didn't "ping!!!!" a reminder until 5 minutes late.

Anyway, last night I was recording a longish movie on the Win7 box. It appears to have been confused - recorded 10 minutes of Sienfeld and missed the last 10 minutes of the movie. This morning, I checked that system's clock - it was fine.

Re:Haha

[Anonymous Coward]

well, its in response for the trolling linsux guys do against windows since the beginning. now you get it!

Some folks are lucky...

[jampola]

...And some are not. Note to self: Do not take a holiday during a leap second!

I had 2 Debian Squeeze Blade servers in Thailand kernel panic on me at 3am (AEST). What strikes me as odd as out of the 6 blades that we have Debian running on (all running squeeze and kernel 2.6.32 with identical packages) only 2 of them had a Panic, and so much for the advisory saying it only affects kernel 2.6.29. There might be more to it than the kernel but sheesh, I'm on holiday!

Re:as of about a year ago, I started defensive cod

[idji]

I am stunned that there are coders out there who write code like i==10. Didn't you get taught in your studies to always think about boundary conditions and write i>9 EVERY TIME?

Re:as of about a year ago, I started defensive cod

[Anonymous Coward]

Watch out we got a bad ass over here... There are situations that i==10 is necessary. Wow you can't think of any?

Re:Haha

[BLT2112]

Windows: 95. Scene: LAN party. Game: Descent.

Off-topic, but I wish I had had more friends with computers back when Descent wasn't ancient. Great game that I would've loved to play multiplayer on more often.

A good description and postmortem here...

[ewwhite]

This was covered well on ServerFault yesterday as someone noticed sudden system instability across their servers.

I dunno about you, but...

[nuckfuts]

I really enjoyed getting to sleep in for that extra second this morning :)

and Qantas

[geoffaus]

and possibly other airlines http://www.news.com.au/travel/news/leap-second-crashes-qantas-and-leaves-passengers-stranded/story-e6frfq80-1226413961235

SLE-11 servers

[Anonymous Coward]

We have a problem with all Novell SLES 11 SP1 servers (both patched and unpatched) that run Java

We experienced very high load from exactly 30 minutes before UTC midnight 30/06/2012. Only virtual servers with a low vCPU core count seem to be affected by the bug ie Load Average of up to 50-100. We only have one physical server with 8 cores and it's still behaving. Symptoms seem to be one java process running at ~75% and ksoftirqd at about 25% is enough to peg the CPU load above 50.

As someone above suggested, setting the date by executing the date command to set the time to the current time seems to resolve the issue and things return to normal:

date `date +"%m%d%H%M%C%y.%S"`

I found stopping/starting ntp daemon has no effect on the efficacy of the work-around.

Re:as of about a year ago, I started defensive cod

[PNHT]

and your code for "if seconds > 58" would run twice....
BOOM
:-(
JUST STOP LEAP SECONDS astronomers can adjust 1/60 of an arc minute every year or so.
The reset of us don't care where the sun is at noon. And if you live in the UK, you don't care where the sun is at noon, you just say "Oooo, look above at the ... the ... uh, bright yellow ball"
Wayne

Re:Haha

[Anonymous Coward]

Was descent peee-to-peer or hosted? Or was it one of the few games back then that could hanle a crashed client in peer-to-peer mode?

But very funny nonetheless.

building backup generator went crazy for an hour

[Anonymous Coward]

The backup generator for my building uses an embedded controller. One of it's functions is to initiate a self test which starts and excercises the engine on the generator for a few minutes once a week.

Yesterday, it went into a loop of starting itself up for one minute and then shutting down. It did this continuously for one hour. I strongly suspect the leap second was the cause.