Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

NTP Glitch Reverts Clocks Back To 2000

Soulskill posted about 2 years ago | from the it's-about-that-time-again dept.

Bug 179

An anonymous reader writes "It seems a glitch of some sort wreaked havoc on some NTP servers yesterday, causing many machines to revert to the year 2000. It seems the Y2K bug that never happened is finally catching up with us in 2012."

Sorry! There are no comments related to the filter you selected.

2012: the end of the world! (5, Funny)

Anonymous Coward | about 2 years ago | (#42046605)

Oh sorry. My clock's off.

2000 ZERO ZERO (5, Funny)

Jeremiah Cornelius (137) | about 2 years ago | (#42046689)

Party's over,
Whoops! Out of time!

Not an NTP glitch (5, Informative)

Anonymous Coward | about 2 years ago | (#42046657)

It was a problem with the USNO servers (I.e. tick.usno.navy.mil, tock.usno.navy.mil etc.) being rebooted and starting to hand out the wrong time. Very few downstream startum 2 NTP servers should have accepted such a large skew, although they may have lost accuracy.

Amusingly I happen to work with an ex. USNO NTP admin, so I'll be sure to take the piss for the rest of the week.

Re:Not an NTP glitch (3, Interesting)

Guspaz (556486) | about 2 years ago | (#42046727)

And end-user systems certainly don't accept that large a skew. ntpd on end-user systems would just have been unable to sync their time while the servers were affected.

Re:Not an NTP glitch (1)

operagost (62405) | about 2 years ago | (#42047027)

Yes. I don't understand how this was a serious issue with any sane configuration.

Re:Not an NTP glitch (2)

lobiusmoop (305328) | about 2 years ago | (#42047215)

end-user UNIX systems at least. TFA talks about Windows AD servers though, maybe they aren't doing the basic sanity checks on the upstream NTP data coming in?

Re:Not an NTP glitch (4, Informative)

Anonymous Coward | about 2 years ago | (#42047407)

Yes and no.
This article is interesting: http://support.microsoft.com/kb/884776
Summary: Windows can do it, but before Server 2008 it defaulted to not doing any sanity checks.
Since 2008 it still is quite generous, allowing 48 hour jumps.
If you don't like it you have to adjust the value in the registry.
I guess it still shows that the Internet was an afterthought for Microsoft...

Re:Not an NTP glitch (2)

tlhIngan (30335) | about 2 years ago | (#42048023)

Windows implements basically Daytime using NTP. What this means is instead of NTPd trying to adjust the clock to be in sync in small increments, Windows does what you do with Daytime instead - query the Daytime server, and set the clock. Except that since very few servers provide Daytime, Microsoft uses NTP to fetch the time and date.

Even the latest Windows still does it - though if it drifts too far, it stops syncing. Very annoying as it doesn't stay synced and quietly fails.

Re:Not an NTP glitch (2)

egamma (572162) | about 2 years ago | (#42047509)

Most windows systems sync to time.microsoft.com.

Re:Not an NTP glitch (0)

Anonymous Coward | about 2 years ago | (#42047725)

Which is always a day late and a dollar short, just to be clear...

CAPTCHA = unsent (really - I'm sending it now!!!!)

Re:Not an NTP glitch (2)

jamesh (87723) | about 2 years ago | (#42047305)

And end-user systems certainly don't accept that large a skew. ntpd on end-user systems would just have been unable to sync their time while the servers were affected.

Had your home router sync'd with such a server and been rebooted, it would have booted with the wrong time, and then wouldn't have accepted the corrected time when the error was fixed...

Re:Not an NTP glitch (1)

wonkey_monkey (2592601) | about 2 years ago | (#42047997)

Had your home router sync'd with such a server and been rebooted, it would have booted with the wrong time, and then wouldn't have accepted the corrected time when the error was fixed...

Why would it have accepted the big skew the first time, but not the second?

Re:Not an NTP glitch (0)

Anonymous Coward | about 2 years ago | (#42048101)

No battery on most of those devices so at boot time it has absolutely no idea what time it is.

The same would be if there was a battery, but the RTC was vastly off which wouldn't be unexpected on cheap devices. Once the error was fixed, it would see the huge skew and ignore it.

Of course rebooting again would fix the issue.

Re:Not an NTP glitch (2)

jamesh (87723) | about 2 years ago | (#42048125)

Had your home router sync'd with such a server and been rebooted, it would have booted with the wrong time, and then wouldn't have accepted the corrected time when the error was fixed...

Why would it have accepted the big skew the first time, but not the second?

A home router would typically not have a battery backed clock, and so on boot would simply accept whatever time it was given by the ntp server. Once it's up and running though it shouldn't accept a 12 year skew. My home router (openwrt) boots to something like 1/1/1970 I think.

Re:Not an NTP glitch (2, Interesting)

Anonymous Coward | about 2 years ago | (#42047797)

Well... My "out of the box" (ie. no special tweaking) Linux on my laptop did accept it...
I had to remove tick & tock.usno.navy.mil from my NTP config.

Re:Not an NTP glitch (2, Informative)

Anonymous Coward | about 2 years ago | (#42047175)

It seems that VMware ESXi servers grabbed the configuration with little issue.

Re:Not an NTP glitch (1, Troll)

bbelt16ag (744938) | about 2 years ago | (#42047239)

roflmao... sorry roflmao sorry... really wow... see this is why we dont use that crap in my home..

Re:Not an NTP glitch (0)

Anonymous Coward | about 2 years ago | (#42048159)

I'll be sure to take the piss for the rest of the week

Careful not to aim into the wind. And for the love of god, stop drinking so much water.

Quck! To The Delorean. (1)

Anonymous Coward | about 2 years ago | (#42046661)

If we don't get to 88 MPH before closing time, we'll never get back to 2012.

Re:Quck! To The Delorean. (0)

Anonymous Coward | about 2 years ago | (#42046927)

Unfortunately, in a DeLorean it'll take forever and a day to get to 88...

Maybe they could improve the algorithm? (1)

Bryansix (761547) | about 2 years ago | (#42046665)

I don't know like a check that says if you are going to change the year (which is rare) that you first verify with three more more devices and seek a consensus?

Re:Maybe they could improve the algorithm? (3, Interesting)

Anonymous Coward | about 2 years ago | (#42046731)

NTP -- at least, the formal Unix client -- already has checks in place to reject huge clock skews like this.

The failure, of course, was dipshit Windows clients talking directly to low-strata servers. And then blindly accepting such a massive skew. Good jorb there, Microsoft, as always.

Re:Maybe they could improve the algorithm? (-1)

Anonymous Coward | about 2 years ago | (#42047053)

Yes, this is all Microsoft's fault because with UNIX apps, you're expected to deal with this sort of bullshit.

Re:Maybe they could improve the algorithm? (1)

0123456 (636235) | about 2 years ago | (#42047905)

To be fair, if you actually need the accuracy NTP provides, you probably shouldn't be running Windows.

Re:Maybe they could improve the algorithm? (1)

wonkey_monkey (2592601) | about 2 years ago | (#42048025)

To be fair, if you actually need the accuracy NTP provides...

...then run NTP on Windows [meinbergglobal.com] .

Re:Maybe they could improve the algorithm? (1)

Richy_T (111409) | about 2 years ago | (#42047425)

Linux fan here. But my Windows 7 boxes will refuse to NTP sync unless the skew is 1 day. It's a bit of a PITA sometimes to be honest.

Re:Maybe they could improve the algorithm? (1)

Richy_T (111409) | about 2 years ago | (#42047439)

< 1 day.

Re:Maybe they could improve the algorithm? (0)

Anonymous Coward | about 2 years ago | (#42047671)

That is because your PCs are not part of a domain, otherwise there would be no limit to the adjustment.
Also the limit should be 15 hours, not one day.
And you can change it (sorry for spamming that link so much): http://support.microsoft.com/kb/884776

Re:Maybe they could improve the algorithm? (0)

Anonymous Coward | about 2 years ago | (#42047683)

GTFO $hill

Re:Maybe they could improve the algorithm? (0)

Anonymous Coward | about 2 years ago | (#42046745)

I'd go with: if the skew exceeds some fraction of the time since the last update, call for help. Either your internal clock's calibration is WAY off, or the other clocks are way off. Either way, you shouldn't be a time server.

Re:Maybe they could improve the algorithm? (2)

Bigby (659157) | about 2 years ago | (#42046923)

Or the computer just traveled near the speed of light.

Re:Maybe they could improve the algorithm? (1)

Anonymous Coward | about 2 years ago | (#42047207)

Or the CMOS battery needs changing.

Re:Maybe they could improve the algorithm? (3, Interesting)

DamonHD (794830) | about 2 years ago | (#42046773)

Generally xntpd and its ilk will not step the time more than a small amount, but will rather give up and quit instead. One machine such as (say) the RPi with no RTC that use ntpdate to *set* rather than *adjust* the clock, this is harder to avoid, but servers should not be automatically running ntpdate when configured properly.

So there may be *two* bugs here to get the problem: one in an NTP implementation and one in use of ntpdate for anything other than manual updates on servers. But I haven't read TFA yet.

(On the little bit of work I put into the ARCRON driver I inserted extra code to look out for year rolls, etc, on top of whatever xntpd would do. In part because ARCRON only sends 2-year dates IIRC.)

Rgds

Damon

Re:Maybe they could improve the algorithm? (1)

operagost (62405) | about 2 years ago | (#42047077)

Simple answer: there is already a sanity limit to prevent adjusting the clock more than x seconds. You have to manually adjust the clock, or manually force a sync to continue in these instances.

The Y2K bug was REAL (5, Insightful)

Anonymous Coward | about 2 years ago | (#42046667)

Why do people keep pretending that it wasn't? It was a real issue, that required real work to fix. If none of that work had happened, it would've hit and it would've hit hard. Celebrate success on occasion, sheesh.

Re:The Y2K bug was REAL (5, Insightful)

asdf7890 (1518587) | about 2 years ago | (#42046775)

Unfortunately most of the general public think that because nothing really went wrong there was not a problem in the first place, and that it was all hyped up by the media. Some of this is the simple truth that it was over-hyped by the media who over-hype everything so people are growing desensitised, some of it is people not bothering to research their opinions or properly engage their critical thinking abilities.

Re:The Y2K bug was REAL (5, Insightful)

mellon (7048) | about 2 years ago | (#42046825)

We have a built-in bias against successful disaster planning: since the planning was successful, the disaster didn't happen, and hence to the average observer, it looks like there wouldn't have been a disaster. The reasoning is flawed, of course, but apparently very hard to resist. This is why governments are only ever harmful—if they do any good, things would have gone well anyway, so they didn't need to spend all that money and go to all that effort. This cognitive flaw is why people who do diving catches are respected, and people who plan for the future and avoid problems are ignored, and why blithering idiots keep getting control of the reins and breaking things.

Re:The Y2K bug was REAL (2)

operagost (62405) | about 2 years ago | (#42047193)

This is why governments are only ever harmful&#226;&#8364;"if they do any good, things would have gone well anyway, so they didn't need to spend all that money and go to all that effort

That's funny, because I always see it in reverse with the US government: if we hadn't had the stimulus, unemployment would have been much worse, or if we didn't have federal loans, no one could afford college, or if we hadn't passed the Patriot Act, we would have had lots of terrorist attacks...

Ignoring, of course, that we have unemployment higher than they predicted anyway, and we have young people racking up debt they can never pay off (and can't be discharged) to gets jobs that don't exist, and we've had terrorist attacks on our military bases, recruiting centers, and embassies.

Re:The Y2K bug was REAL (-1)

Anonymous Coward | about 2 years ago | (#42047253)

Governments are harmful. That they may provide a benefit for some people in some situations ignores the fact that they had to use force to obtain that benefit from others.

Re:The Y2K bug was REAL (1)

jamesh (87723) | about 2 years ago | (#42047327)

Governments are harmful. That they may provide a benefit for some people in some situations ignores the fact that they had to use force to obtain that benefit from others.

Close. Harmful governments are harmful, just like obvious troll is obvious.

Re:The Y2K bug was REAL (1)

mcrbids (148650) | about 2 years ago | (#42047321)

To be fair, it makes a bit of sense. I know, it sounds dumb, but the horrible truth is that being prepared can be rather expensive and the cost of preparing for every possibility is utterly infeasible.

To be evolutionarily successful, you need to be prepared enough to survive long enough to reproduce, and perhaps to see that your offspring reproduce. Being prepared to live 100 years when you won't breed much past 35 means that there's up to 65 years of time where your cost/benefit to the gene pool drops to near zero.

Clearly, it's not an exactly calculable range, and there are certainly plenty of variables, and I'm not saying that you shouldn't be prepared. But on the other hand, there's certainly justification to be biased against being overprepared.

Re:The Y2K bug was REAL (1)

Bigby (659157) | about 2 years ago | (#42046841)

People want to believe that preparation and work can't actually succeed. Just like the Hoover Dam doesn't really exist, because it would be hard to do. Same with landing on the moon. Actually, when you think about it, everyone believes we built the Hoover Dam with hard work. Most believe we landed on the moon. And only some think that Y2K was a real issue. It seems like people are getting less and less accepting of difficult tasks.

Re:The Y2K bug was REAL (1)

19thNervousBreakdown (768619) | about 2 years ago | (#42048227)

Or maybe the difficult tasks we accomplish are getting more and more intangible, and it's human nature to doubt what you can't see or imagine.

You can go up and touch the Hoover Dam.

You can at least look at the moon, although people don't really have much concept of the distances involved, and most people don't even know someone who was in outer space.

To understand the Y2K bug, you practically need to have a theory of mind for computers, and understand that things that are extremely simple for a person--reasoning the century of a 2-digit date from context, not having an aneurysm when you encounter 4 digits where you were expecting 2--are practically impossible for a computer, which has no concept of context as we understand it, or any concepts at all, really.

People have a very hard time shaking the idea that the computer can think. Next time you hear someone complain about some bug, or (especially) missing feature, really pay attention to what they're saying. 9 out of 10 times, you'll hear some variation of, "Come on! How hard is it to ... ?" where the answer is "it's not hard at all for a person to do it" and "it's very very very hard for a person to make a computer do it".

Re:The Y2K bug was REAL (0)

Anonymous Coward | about 2 years ago | (#42046875)

It's still not fixed. My bank statements say the year is 112.

Re:The Y2K bug was REAL (2)

Cinder6 (894572) | about 2 years ago | (#42046983)

Not sure why you expect a bank, of all things, would get basic things right...

Re:The Y2K bug was REAL (1)

joaosantos (1519241) | about 2 years ago | (#42047385)

My a suggest using a different bank?

Re:The Y2K bug was REAL (1, Insightful)

c0lo (1497653) | about 2 years ago | (#42046919)

Why do people keep pretending that it wasn't? It was a real issue, that required real work to fix

"the Y2K bug that never happened" != "the Y2K bug that never existed".

So, what's your point again?

Re:The Y2K bug was REAL (1)

Bigby (659157) | about 2 years ago | (#42046989)

The bug happened. The symptoms of the bug never happened. Big difference. That's like saying a car without a brakes never happened. The context doesn't make sense. Now, a car without brakes drove away and was unable to stop? That would happen.

Re:The Y2K bug was REAL (1)

Cinder6 (894572) | about 2 years ago | (#42046925)

Probably because of sensationalist news outlets that claimed all sorts of things would go wrong, such as cars not starting, missiles being launched spontaneously, etc.

Re:The Y2K bug was REAL (4, Interesting)

ShanghaiBill (739463) | about 2 years ago | (#42046957)

Why do people keep pretending that it wasn't? It was a real issue, that required real work to fix. If none of that work had happened, it would've hit and it would've hit hard.

Lots of organizations worked hard to prepare for Y2K. Lots of other organizations did absolutely nothing to prepare. Neither had any significant problems on 1/1/2000. The reason is there were very few problems to begin with. The myth was that back when memory was precious, programmers stored the year in two bytes instead of four. But those of us that actually programmed in the days when 4K was a LOT of RAM, know that we never used two ASCII chars to store a year. We used a single byte to store the offset from 1900 in binary. So there will be no overflow until 2156.

Re:The Y2K bug was REAL (1)

Bigby (659157) | about 2 years ago | (#42047121)

Those were for people who used an appropriate YEAR or DATE data type. Many like to you CHAR data types. In fact, I am dealing with one right now. The schema was created only 4 years ago and stores date/time in CHAR data types. I guess they didn't want to do the work of parsing that data.

Re:The Y2K bug was REAL (0)

Anonymous Coward | about 2 years ago | (#42047127)

Don't worry, the Y2038 problem [wikipedia.org] will have long prevented us from reach 2156.

Re:The Y2K bug was REAL (2, Interesting)

Anonymous Coward | about 2 years ago | (#42047173)

Lots of organizations worked hard to prepare for Y2K. Lots of other organizations did absolutely nothing to prepare. Neither had any significant problems on 1/1/2000. The reason is there were very few problems to begin with. The myth was that back when memory was precious, programmers stored the year in two bytes instead of four.

While I'm sure plenty of organizations did nothing and were fine, I know for a fact that storing years as two bytes was not a myth. At my organization I fixed such a problem in critical systems. We would have had people collecting GPS data in the field with no way to verify it's quality if I hadn't. Not doom for our organization, but not a "myth" as you call it.

Re:The Y2K bug was REAL (1)

0123456 (636235) | about 2 years ago | (#42048129)

I lost several days of simulation work that had been running over Christmas. Again, not a big deal because I restarted it when I got back in January, but still a real Y2K bug that we hadn't found or fixed.

Re:The Y2K bug was REAL (1)

operagost (62405) | about 2 years ago | (#42047257)

2038 for unix, cuz greybeards used 32 bit signed offsets in seconds. Or perhaps 2027 if you forgot to make that single byte integer unsigned.

Re:The Y2K bug was REAL (1)

Vanders (110092) | about 2 years ago | (#42047731)

Not since POSIX invented time_t. time_t is 64 bit long on most systems these days. You'll only be in trouble if you're still running a UNIX with a 32bit time_t in 2038; the chances seem remote.

Re:The Y2K bug was REAL (3, Interesting)

BobNET (119675) | about 2 years ago | (#42047329)

We used a single byte to store the offset from 1900 in binary.

Most TRS-80 operating systems figured 3 bits was enough [trs-80.org] to store an offset from 1980, so we've already lived through the Y1.988k bug.

Re:The Y2K bug was REAL (1)

Carewolf (581105) | about 2 years ago | (#42047537)

It was a problem in COBOL and some databases. If you had no COBOL you would usually be fine. Many banks however have very old code, and they needed to have this problem fixed in 2000, and they got it fixed. Checking for Y2K problems was checking for COBOL code and particular patterns of programming and database-design where 2 chars were used for years.

Re:The Y2K bug was REAL (1)

Darinbob (1142669) | about 2 years ago | (#42048389)

It was a problem in many places. Y2K bugs did crop up. Some cropped up as early as 1996, a lot more showed up in '98 and '99. By then most of the major stuff had been figured out.

COBOL is only significant here because it is the most common language used in some financial operations. However the problem existed in C, assembler, Fortran, Java, databases, etc. Yes, I hear someone say "but my favorite language has a Date type!", which really only matters if the original programmer used the date type correctly. I have even seen code written after 1990 with obvious Y2K problems in it. It is not hard at all to find code written this decade by junior programmers that completely fails to understand some basic stuff about dates.

(I notice that the original version of Zork written in Muddle has a Y2K bug in it. It got the time/date from operating system in a single 36 bit word, and the year took up 7 bits. So it could tell you "This Zork created November 20, 19112.")

Re:The Y2K bug was REAL (2)

Cartotype (1158091) | about 2 years ago | (#42048263)

I know of at least one organization which had a significant Y2K problem, even after making preparations.

Sadly, the preparations were "Hire someone to take the fall when the shit hits the fan so we can continue with business as usual. Er... hire someone to ensure Y2K preparedness."

The fatal glitch in the plan was that the person who got hired made friends with an exec in the parent company before the ball dropped. So, when things went south the hire got a silver parachute while the rest of the company folded.

Quite a mess. Should certainly count as a "significant problem".

and the 2038 bug as well as the Year 2042 bug (2)

Joe_Dragon (2206452) | about 2 years ago | (#42047883)

and the 2038 bug as well as the Year 2042 bug are still to come.

Also maybe a Day 32,768 and 65,536 bug as well.

Re:The Y2K bug was REAL (1)

jjeffries (17675) | about 2 years ago | (#42048105)

I never had my own internal Y2K bug fixed. I keep writing "19112" on paperwork.

Those damn Mayan's!!! (1)

Supp0rtLinux (594509) | about 2 years ago | (#42046671)

The Mayan's are up to something sinister what did they know that we don't?

Re:Those damn Mayan's!!! (1)

mcgrew (92797) | about 2 years ago | (#42046943)

The Mayan's are up to something sinister

The Mayan's WHAT are up to something similar? Their goats? Their sheep? Their calendars? Don't keep us in suspense, man!

Re:Those damn Mayan's!!! (1)

Cinder6 (894572) | about 2 years ago | (#42047007)

The Mayan's are. It's a lot like an alot [blogspot.com] .

Why 2000? (0)

Anonymous Coward | about 2 years ago | (#42046695)

I wanted to party like it's 1999 :(

Re:Why 2000? (1)

aliquis (678370) | about 2 years ago | (#42046893)

Quick! Sell your Nokia stocks! :D

Re:Why 2000? (0)

Anonymous Coward | about 2 years ago | (#42047481)

Any excuse to resurrect a 10 year old joke. YEAH BABY YEAH.

Not a Y2K bug according to TFA (1)

Anonymous Coward | about 2 years ago | (#42046697)

There's no indication in the linked article that this was related to a Y2K bug. Rather, an authoritative server accidentally had its clock reset, and that seems to have propagated.

Re:Not a Y2K bug according to TFA (1)

Bigby (659157) | about 2 years ago | (#42046865)

But why did it reset to the year 2000? Why not to epoch: Jan 1 1970? Is 2000 the new epoch?

Re:Not a Y2K bug according to TFA (1)

Anonymous Coward | about 2 years ago | (#42047087)

No idea, but probably not because the "year" field reached "99" and rolled around, which is what a Y2K bug would have looked like.

RTFA (2, Funny)

Anonymous Coward | about 2 years ago | (#42046747)

For those of you who didn't read the article; US Naval Observatory rebooted one of their NTP servers (tock.usno.navy.mil I believe, though not sure), and the server's time reverted to 2000.. This time change got pushed out, and thus people freaked out claiming that NTP was broken.

A lesson can be learned from this: change your BIOS battery when it's dead (alternatively, never reboot your servers).

The Y2K bug (5, Insightful)

geekoid (135745) | about 2 years ago | (#42046779)

did happen. The Y2K disaster did not thanks to a lot of money and a lot of people working to fix the bug.

Re:The Y2K bug (5, Funny)

PPH (736903) | about 2 years ago | (#42046831)

Trust the computer industry to shorten the term "Year 2000" to Y2K.

It was this kind of thinking that got them in trouble in the first place.

Re:The Y2K bug (1)

Cinder6 (894572) | about 2 years ago | (#42047039)

I recently saw "2k12" written somewhere. *sigh*

Re:The Y2K bug (1)

cdrudge (68377) | about 2 years ago | (#42047437)

Trust the computer industry to shorten the term "Year 2000" to Y2K.

It was this kind of thinking that got them in trouble in the first place.

What's wrong with Y2K? 2K = 2000. The problem with Y2K was that they shortened 2000 to 00, dropping the most significant digits. Not just substituting 3 digits (000) with a letter (K).

Re:The Y2K bug (0)

Anonymous Coward | about 2 years ago | (#42047921)

So this would be... NTFU ?

Re:The Y2K bug (2)

MobyDisk (75490) | about 2 years ago | (#42048355)

Wait, isn't Y2K going to happen in 2048?

Re:The Y2K bug (1)

c0lo (1497653) | about 2 years ago | (#42046985)

did happen. The Y2K disaster did not thanks to a lot of money and a lot of people working to fix the bug.

Strange terminology you have here.
Yes, the Y2K bugs was real and yes, a lot of people worked to fix it. Making the bug to... hold on... not happen (because by that time it was removed/fixed).

Terminology... (1)

tilante (2547392) | about 2 years ago | (#42047315)

Just as a single word can have multiple meanings, a single phrase can have multiple meanings as well. The Y2K bug that a lot of people (including me!) helped fix, yes, that was real. However, the Y2K bug that some nutcases hyped, where everything that had a clock chip in it would go haywire at 00:00:01 Jan 1, 2000, did not exist.

It's like person A saying "dragons don't exist", and person B replying, "Yes, they do! The komodo dragon is a real animal!" The komodo dragon is a dragon, but it's not the kind of dragon person A is talking about. In the same way, there was a real thing called the Y2K bug, but it's not the same thing that most people are talking about when they say "the Y2K bug was a myth" or "the Y2K bug didn't happen".

And in any case, it should be obvious that the original poster is making a joke. I refer people to TVTropes' "Rule of Funny". (Which only somewhat works here, since the joke wasn't that funny, but the guy was trying.)

Re:The Y2K bug (1)

ShanghaiBill (739463) | about 2 years ago | (#42047135)

did happen. The Y2K disaster did not thanks to a lot of money and a lot of people working to fix the bug.

Yet lots of other people did absolutely nothing, and the disaster didn't happen for them either. I worked on Y2K. When we were testing, we tried booting early versions of MSDOS, Windows, OS/2, Linux, FreeBSD, MacOS. The older the better. None of these had a problem when the date transitioned. Or at least (in the case of Windows 3.0), nothing that a reboot wouldn't fix. The situation was similar with applications. We found a few applications that needed to be restarted after the date transitioned, but there were no show stoppers.

Y2K was hyped up by the press and by software vendors peddling "critical" upgrades.

Re:The Y2K bug (1)

Bigby (659157) | about 2 years ago | (#42047219)

In most instances, it would have been simply a nuisance. However, there are certain applications and systems that rely more heavily on dates that would have been a disaster. Those were the ones that were addressed properly. Just think of what a few seconds of differentiation does to GPS. Certain financial, insurance, etc... systems would have been quite unpredictable.

Re:The Y2K bug (1)

jamesh (87723) | about 2 years ago | (#42047403)

did happen. The Y2K disaster did not thanks to a lot of money and a lot of people working to fix the bug.

Yet lots of other people did absolutely nothing, and the disaster didn't happen for them either. I worked on Y2K. When we were testing, we tried booting early versions of MSDOS, Windows, OS/2, Linux, FreeBSD, MacOS. The older the better. None of these had a problem when the date transitioned. Or at least (in the case of Windows 3.0), nothing that a reboot wouldn't fix. The situation was similar with applications. We found a few applications that needed to be restarted after the date transitioned, but there were no show stoppers.

Y2K was hyped up by the press and by software vendors peddling "critical" upgrades.

the realtime clock in your PC bios in that era stored the date in BCD form (4 bits per digit) and often either had a problem at transition, or just didn't work. Easily fixable with a boot-time patch or something, but still a problem that needed to be addressed.

The satellite images at www.bom.vic.gov.au showed the year as 19100 for a while. Again, not a show stopper but still an indication that someone didn't fix a problem that should have been fixed.

Properly configured hosts not impacted (5, Informative)

jaredmauch (633928) | about 2 years ago | (#42046843)

If you saw this problem, your NTP time sources were not properly configured and diverse.

Consider using the NTP pool and not relying on so few sources to properly sync your time. Read 5.3.3 and 5.3.4 from http://support.ntp.org/bin/view/Support/SelectingOffsiteNTPServers [ntp.org] for help to correct your NTP setup.

Re:Properly configured hosts not impacted (0)

Anonymous Coward | about 2 years ago | (#42047281)

More to the point, you should probably either a) Stop syncing from stratum 1 or b) configure your stratum 2 servers properly.

Any server that accepted a skew of -12 years is broken.

Re:Properly configured hosts not impacted (1)

Anonymous Coward | about 2 years ago | (#42047455)

So all Microsoft PCs/servers before 2008 version are broken: http://support.microsoft.com/kb/884776

Re: Properly configured hosts not impacted (0)

Anonymous Coward | about 2 years ago | (#42048043)

Nothing new about that.

Re:Properly configured hosts not impacted (1)

Just Some Guy (3352) | about 2 years ago | (#42048119)

What does that have to do with NTP?

Re:Properly configured hosts not impacted (1)

operagost (62405) | about 2 years ago | (#42047285)

If you saw this problem, consider properly setting your sanity interval.

Re:Properly configured hosts not impacted (0)

Anonymous Coward | about 2 years ago | (#42047871)

I saw the problem because cisco call managers complained when the domain controller was no longer a trusted time source. The domain controller is configured with exactly one upstream provider because our ISP (government) in their wisdom have blocked ntp to anything but their time servers (sigh).

Note though that no services were affected, but lots of errors were generated. I thought it odd that it was complaining that it would not update the time because it was off by something like -378691200 seconds, which seemed strange. However external time servers are out of my control so i just ignored the errors and waited it out. Happened about 13:25 PST.

Re:Properly configured hosts not impacted (0)

Anonymous Coward | about 2 years ago | (#42048311)

Indeed. However, it needs to be noted that a lot of operating systems, out of the box, only let you sync to a single source. Redundancy? What's that? Oh, you mean adding in extra servers that normally will be doing nothing? Too expensive; who's going to pay for this? Cut it out, trim the fat, run it nice and lean so the managers can get an extra $1000 on their bonuses ...

RIP Charles M. Schulz (2)

Ol Biscuitbarrel (1859702) | about 2 years ago | (#42046849)

Poor Elián González! At least I was able to get ILOVEYOU off of my Gateway. Have you checked out Dora the Explorer?

Re:RIP Charles M. Schulz (1)

operagost (62405) | about 2 years ago | (#42047389)

I say, old chap, I haven't a clue what you mean! Things are right bully here in the year 1900! Why, the economy is booming under the gold standard, President McKinley has just been reelected, and I eagerly await the brilliant plans he has in store for his second term! What's the worst that could happen?

That's What Happens... (1)

Epicaxia (2773451) | about 2 years ago | (#42046871)

...when you forget to put the correct cover on your TPS report.

But did it skew the pool ? (2)

SimplexBang (2685909) | about 2 years ago | (#42046913)

pool.ntp.org is our one and only external resource that we need .

My work was effected (2)

bufke (2029164) | about 2 years ago | (#42047125)

Last night AD went to year 2000. Linux clients joined to AD freaked out right away with scary security warnings. A reboot fixed them right away after AD time was set right. Or setting time manually.

Windows had authentication trouble so Shares, Printers, etc stop working for clients. For some reason I had to rebooting them many times fixed them, no idea why one wasn't enough. Had trouble reported all today even though it was only off for 2 hours last night.

Hard to believe Windows doesn't do sanity checking on this stuff.

Re:My work was effected (0)

Anonymous Coward | about 2 years ago | (#42047529)

You should enable the sanity checking: http://support.microsoft.com/kb/884776
(Yes, stupid that they had it disabled by default up to Server 2008)

Re:My work was effected (1)

Capt.DrumkenBum (1173011) | about 2 years ago | (#42047557)

Hard to believe Windows doesn't do sanity checking on this stuff.

Are you new here? Microsoft has a long history of not sanity checking, damn near anything until long after it breaks.

No Warning?! (2)

organgtool (966989) | about 2 years ago | (#42047485)

Why didn't you warn us about this time-based bug, John Titor?!

This happened to me in 1999 (2)

MichaelSmith (789609) | about 2 years ago | (#42047607)

Our NTP sync came from a remote site and they were doing Y2K testing. Clocks jumped forward to March 2000 and screwed up the timestamps on our binaries. In the end we had to touch backwards to get our build system working again.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?