NTP Glitch Reverts Clocks Back To 2000

← Back to Stories (view on slashdot.org)

NTP Glitch Reverts Clocks Back To 2000

Posted by Soulskill on Tuesday November 20, 2012 @09:07AM from the it's-about-that-time-again dept.

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."

179 comments

Min score:

Reason:

Sort:

2012: the end of the world! by Anonymous Coward · 2012-11-20 09:09 · Score: 5, Funny

Oh sorry. My clock's off.
Not an NTP glitch by Anonymous Coward · 2012-11-20 09:13 · Score: 5, Informative

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.
1. Re:Not an NTP glitch by Guspaz · 2012-11-20 09:18 · Score: 3, Interesting
  
  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.
2. Re:Not an NTP glitch by operagost · 2012-11-20 09:39 · Score: 1
  
  Yes. I don't understand how this was a serious issue with any sane configuration.
  
  --
  
  Gamingmuseum.com: Give your 3D accelerator a rest.
3. Re:Not an NTP glitch by Anonymous Coward · 2012-11-20 09:48 · Score: 2, Informative
  
  It seems that VMware ESXi servers grabbed the configuration with little issue.
4. Re:Not an NTP glitch by lobiusmoop · 2012-11-20 09:51 · Score: 2
  
  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?
  
  --
  "I bless every day that I continue to live, for every day is pure profit."
5. Re:Not an NTP glitch by bbelt16ag · 2012-11-20 09:52 · Score: 1, Troll
  
  roflmao... sorry roflmao sorry... really wow... see this is why we dont use that crap in my home..
  
  --
  NEVER NEVER NEVER NEVER NEVER NEVER NEVER NEVER GIVE UP! "No limitations, no boundaries, there is no reason for them."
6. Re:Not an NTP glitch by jamesh · 2012-11-20 09:55 · Score: 2
  
  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...
7. Re:Not an NTP glitch by Anonymous Coward · 2012-11-20 10:02 · Score: 4, Informative
  
  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...
8. Re:Not an NTP glitch by egamma · 2012-11-20 10:09 · Score: 2
  
  Most windows systems sync to time.microsoft.com.
  
  --
  Battlemaster--Game with friends in medival realms
9. Re:Not an NTP glitch by Anonymous Coward · 2012-11-20 10:22 · Score: 0
  
  Which is always a day late and a dollar short, just to be clear...
  CAPTCHA = unsent (really - I'm sending it now!!!!)
10. Re:Not an NTP glitch by Anonymous Coward · 2012-11-20 10:28 · Score: 2, Interesting
  
  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.
11. Re:Not an NTP glitch by wonkey_monkey · 2012-11-20 10:42 · Score: 1
  
  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?
  
  --
  systemd is Roko's Basilisk.
12. Re:Not an NTP glitch by tlhIngan · 2012-11-20 10:44 · Score: 2
  
  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.
13. Re:Not an NTP glitch by Anonymous Coward · 2012-11-20 10:49 · Score: 0
  
  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.
14. Re:Not an NTP glitch by jamesh · 2012-11-20 10:50 · Score: 2
  
  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.
15. Re:Not an NTP glitch by Anonymous Coward · 2012-11-20 10:53 · Score: 0
  
  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.
16. Re:Not an NTP glitch by Anonymous Coward · 2012-11-20 11:19 · Score: 1
  
  This issue raises its ugly head in any environment that uses BlackBerry Enterprise Server 5.x with Microsoft Active Directory. A clock skew of more than 5 minutes and the BlackBerry Administration Service web console cannot be accessed; that is to say you cannot successfully login to the web console.
17. Re:Not an NTP glitch by Anonymous Coward · 2012-11-20 11:31 · Score: 0
  
  ntpdate -b ntp.server.dom is pretty common to sync clock before starting ntp.
  Also not positive what a host with only these peers, and iburst after the server name in ntpd.conf would do... I suspect this config would be affected too. With the exception of "only these peers", this is a fairly common config for those NOT pre-syncing time with ntpdate too.
18. Re:Not an NTP glitch by master_kaos · 2012-11-20 11:48 · Score: 1
  
  I have a coworker that says the same thing all the time, and I find it annoying. In reality he means either "no", but in most cases, "sort of"
19. Re:Not an NTP glitch by Anonymous Coward · 2012-11-20 12:47 · Score: 1
  
  It is short hand for "Depends on the details of what you are asking, such as how you define the boundary between yes and no, so I will give you a detailed/numeric answer that lets you apply your own, previously unspecified boundaries to yield a binary answer if needed." If you want to condition people to put things into binary answers on demand, expect some miscommunication issues.
20. Re:Not an NTP glitch by HideyoshiJP · 2012-11-20 15:06 · Score: 1
  
  Wouldn't that be an issue with anything using AD authentication? I thought Kerberos required the client's time to be within five minutes of the authentication server.
21. Re:Not an NTP glitch by davester666 · 2012-11-20 16:43 · Score: 0
  
  AD != Kerberos
  
  --
  Sleep your way to a whiter smile...date a dentist!
22. Re:Not an NTP glitch by HideyoshiJP · 2012-11-20 20:17 · Score: 1
  
  No, but I do believe it's the default authentication method for Windows systems.
23. Re:Not an NTP glitch by Anonymous Coward · 2012-11-20 20:28 · Score: 0
  
  So it has to accept a 42 years skew on boot. In practice it must accept anything positive.
  Some sanity checks may be implemented in the firmware (only accepts dates past the firmware release date), but
  it's unlikely that it can do much more (would need some persistent storage, but flash wears out and everything else
  adds to cost).
24. Re:Not an NTP glitch by hawkinspeter · 2012-11-20 20:59 · Score: 1
  
  Is light a particle?
  
  --
  You're a temporary arrangement of matter sliding towards oblivion in a cold, uncaring universe
25. Re:Not an NTP glitch by Anonymous Coward · 2012-11-20 21:41 · Score: 0
  
  Well, I did expain in the rest of the comment.
  No if you use the default configuration, your server is part of a domain and is not Server 2008. Yes otherwise.
  So when asking about the whole group of "Windows AD servers" the answer is yes for some and no for some others, thus the answer is really both yes and no.
  But if it you irks you that much consider it a result of me not being a native speaker, I don't think I've ever used that construct in any other language.
26. Re:Not an NTP glitch by AmiMoJo · 2012-11-21 01:19 · Score: 2
  
  As it happens I recently implemented the RTC in an embedded product and used a simple trick to reject obviously wrong times. I compare the date with the firmware build date and reject it if it is earlier. In the case of a router it could easily try other NTP servers in that case.
  That simple test rejects 99% of incorrect dates where something has been reset and started from zero again (which in this case would seem to be 01/01/2000).
  
  --
  const int one = 65536; (Silvermoon, Texture.cs)
  SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
27. Re:Not an NTP glitch by poofmeisterp · 2012-11-21 06:15 · Score: 1
  
  Yes. I don't understand how this was a serious issue with any sane configuration.
  Article says,
  
  "We are seeing some reports that some Active Directory Domains times reverting to November 2000."
  That may have been useful in the article's title, or hell, even the body.
28. Re:Not an NTP glitch by Anonymous Coward · 2012-11-21 07:20 · Score: 0
  
  Windows AD does accept a 12 year skew. I know, because for about a half hour a lot of critical client applications here, dependent on knowing the date, were not behaving correctly. Knew it was happening about fifteen minutes after errors started cropping up right and left. Went and manually corrected the year on the domain server and suddenly all was better again.
Quck! To The Delorean. by Anonymous Coward · 2012-11-20 09:13 · Score: 1

If we don't get to 88 MPH before closing time, we'll never get back to 2012.
1. Re:Quck! To The Delorean. by Anonymous Coward · 2012-11-20 09:33 · Score: 0
  
  Unfortunately, in a DeLorean it'll take forever and a day to get to 88...
2. Re:Quck! To The Delorean. by DarwinSurvivor · 2012-11-21 10:51 · Score: 1
  
  You just need more power!
Maybe they could improve the algorithm? by Bryansix · 2012-11-20 09:13 · Score: 1

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?
1. Re:Maybe they could improve the algorithm? by Anonymous Coward · 2012-11-20 09:19 · Score: 3, Interesting
  
  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.
2. Re:Maybe they could improve the algorithm? by Anonymous Coward · 2012-11-20 09:20 · Score: 0
  
  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.
3. Re:Maybe they could improve the algorithm? by DamonHD · 2012-11-20 09:22 · Score: 3, Interesting
  
  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
  
  --
  http://m.earth.org.uk/
4. Re:Maybe they could improve the algorithm? by Bigby · 2012-11-20 09:33 · Score: 2
  
  Or the computer just traveled near the speed of light.
5. Re:Maybe they could improve the algorithm? by operagost · 2012-11-20 09:42 · Score: 1
  
  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.
  
  --
  
  Gamingmuseum.com: Give your 3D accelerator a rest.
6. Re:Maybe they could improve the algorithm? by Anonymous Coward · 2012-11-20 09:50 · Score: 1
  
  Or the CMOS battery needs changing.
7. Re:Maybe they could improve the algorithm? by Richy_T · 2012-11-20 10:03 · Score: 1
  
  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.
8. Re:Maybe they could improve the algorithm? by Richy_T · 2012-11-20 10:04 · Score: 1
  
  < 1 day.
9. Re:Maybe they could improve the algorithm? by Anonymous Coward · 2012-11-20 10:19 · Score: 0
  
  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
10. Re:Maybe they could improve the algorithm? by Anonymous Coward · 2012-11-20 10:20 · Score: 0
  
  GTFO $hill
11. Re:Maybe they could improve the algorithm? by 0123456 · 2012-11-20 10:35 · Score: 1
  
  To be fair, if you actually need the accuracy NTP provides, you probably shouldn't be running Windows.
12. Re:Maybe they could improve the algorithm? by wonkey_monkey · 2012-11-20 10:44 · Score: 1
  
  To be fair, if you actually need the accuracy NTP provides...
  ...then run NTP on Windows.
  
  --
  systemd is Roko's Basilisk.
13. Re:Maybe they could improve the algorithm? by Bryansix · 2012-11-20 11:28 · Score: 1
  
  How exactly would that happen? Wouldn't it be the administrator's fault? I set all my domain controllers to talk to us.pool.ntp.org
14. Re:Maybe they could improve the algorithm? by Stupendoussteve · 2012-11-20 17:19 · Score: 1
  
  Honestly not sure... it did hit us on a couple of old boxes, but fixed itself pretty quickly, and we definitely weren't using the affected navy servers. tick and tock are supposed to be used only by gov, and stratum 2 servers. Maybe some servers forwarded the wrong information?
15. Re:Maybe they could improve the algorithm? by Pieroxy · 2012-11-20 22:05 · Score: 2
  
  Yes, this is all Microsoft's fault because with UNIX apps, you're expected to deal with this sort of bullshit.
  You SHOULD expect this kind of bullshit. Because in real life, shit happens. Servers do reboot. Servers do see their clocks reset. Yes, even time servers.
  In general, YOU are responsible for your own system. You may query other servers to check their time, but in the end, it's your program that sets your computer's time, so it's its own responsibility to do the right thing.
  A check against something obviously wrong is just common sense.
  
  --
  Write boring code, not shiny code!
16. Re:Maybe they could improve the algorithm? by Anonymous Coward · 2012-11-21 00:34 · Score: 0
  
  Please don't do that. You should only sync the DC holding the "PDC Emulator" FSMO role to an external source. All other DC's will sync against the PDC emulator.
17. Re:Maybe they could improve the algorithm? by Anonymous Coward · 2012-11-21 01:53 · Score: 1
  
  Funnily enough, using ntpdate instead of ntpd is recommended by the NSA Linux hardening guidelines due to issues with ntpd over the years (see page 2):
  http://www.nsa.gov/ia/_files/factsheets/rhel5-pamphlet-i731.pdf
18. Re:Maybe they could improve the algorithm? by Richy_T · 2012-11-21 04:54 · Score: 1
  
  Interesting. Thanks.
19. Re:Maybe they could improve the algorithm? by cthulhu11 · 2012-11-21 10:03 · Score: 1
  
  First you write:
  
  Generally xntpd and its ilk will not step the time more than a small amount, but will rather give up and quit instead.
  but then you write:
  but servers should not be automatically running ntpdate when configured properly.
  These ideas conflict. It is common practice to run ntpdate at boot-time so that the time gets close enough for ntpd to manage, without this ntpd will often twiddle its thumbs indefinitely.
20. Re:Maybe they could improve the algorithm? by Bryansix · 2012-11-21 12:44 · Score: 1
  
  Almost all the domains I Administer have only one DC. In the ones that have more then one, I am aware of the fact that only the PDC Emulator should sync externally.
21. Re:Maybe they could improve the algorithm? by DamonHD · 2012-11-21 19:57 · Score: 1
  
  I think that it is poor practice to run ntpdate at boot; instead make sure that the underlying RTC is being set to match the ntp-managed OS clock (with appropriate options on xntpd if necessary) and then there is no reason for the system clock to be far from reality at boot. If there is a big discrepancy, a human should investigate/fix.
  Rgds
  Damon
  
  --
  http://m.earth.org.uk/
22. Re:Maybe they could improve the algorithm? by cthulhu11 · 2012-11-21 20:10 · Score: 1
  
  I think that it is poor practice to run ntpdate at boot;
  Give me a viable alternative.
  
  instead make sure that the underlying RTC is being set to match the ntp-managed OS clock
  Sorry, my magic wand's in the shop.
  
  (with appropriate options on xntpd if necessary)
  Such as? And last I checked they went back to calling it just ntpd, did I miss something?
  
  and then there is no reason for the system clock to be far from reality at boot.
  
  It doesn't have to be very far off to prevent ntpd from carrying on, and there are plenty of reasons, including mobo swaps, shipping hardware around $continent, and systems coming from the factory with the time off by months.
  
  If there is a big discrepancy, a human should investigate/fix.
  Sounds like a job for a computer to me.
23. Re:Maybe they could improve the algorithm? by DamonHD · 2012-11-22 05:13 · Score: 1
  
  Hi,
  The last versions of NTP that I contributed to, and paid close attention to when I was providing stratum-1 service, had a flag something like --syncRTC to force the OS to update the underlying battery-backed clock to the 'right' time from its software clock, and thus it would stay close enough during a reboot that (x)ntpd would be happy to pick up again.
  My view remains that if a real-time clock is WAY off then it should be manually investigated and manually corrected, eg when I found some remote and local machines at BigMultimationalCo being set to the right local time but completely the wrong timezones, so in reality many many hours out. The fix partly included user education in that case, rather than much technology.
  Views differ: I'm sure your systems work fine. I'm just telling you how I have run NTP as a public time source and for hundreds of boxes on clients' networks.
  Now that I'm not providing low-stratum time I'm a bit more relaxed about it, but my diversity of input sources seems to have saved me this time (I have 6 upstream sources for my primary NTP server).
  Rgds
  Damon
  
  --
  http://m.earth.org.uk/
24. Re:Maybe they could improve the algorithm? by DamonHD · 2012-11-22 05:51 · Score: 1
  
  I note an option on ntpd on my Ubuntu 9 box:
  -x Normally, the time is slewed if the offset is less than the step
  threshold, which is 128 ms by default, and stepped if above the
  threshold. This option sets the threshold to 600 s ...
  which would still avoid this problem with an insane upstream, but would allow more leeway for a drifting clock to be brought back into sync, but 600s would take 14 days to slew back, so I'd still manually force it with ntpdate in that case almost certainly, since make and so on would be unhappy for most of that fortnight otherwise.
  Rgds
  Damon
  
  --
  http://m.earth.org.uk/
25. Re:Maybe they could improve the algorithm? by cthulhu11 · 2012-11-22 11:58 · Score: 1
  
  Hi,
  The last versions of NTP that I contributed to, and paid close attention to when I was providing stratum-1 service, had a flag something like --syncRTC to force the OS to update the underlying battery-backed clock to the 'right' time from its software clock, and thus it would stay close enough during a reboot that (x)ntpd would be happy to pick up again.
  And how does it get "close enough" in the first place? For a system to reboot, it has to boot in the first place. When a system comes from the factory with the date off by three months, it's not going to magically get close enough for ntpd to take over without an nptdate invocation.
26. Re:Maybe they could improve the algorithm? by DamonHD · 2012-11-22 19:41 · Score: 1
  
  And along with all other admin/config that a sysadmin forces on that new machine at that point, forcing the clock to be correct is easy.
  Rgds
  Damon
  
  --
  http://m.earth.org.uk/
The Y2K bug was REAL by Anonymous Coward · 2012-11-20 09:14 · Score: 5, Insightful

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.
1. Re:The Y2K bug was REAL by asdf7890 · 2012-11-20 09:22 · Score: 5, Insightful
  
  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.
2. Re:The Y2K bug was REAL by mellon · 2012-11-20 09:27 · Score: 5, Insightful
  
  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.
3. Re:The Y2K bug was REAL by Bigby · 2012-11-20 09:28 · Score: 1
  
  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.
4. Re:The Y2K bug was REAL by Anonymous Coward · 2012-11-20 09:29 · Score: 0
  
  It's still not fixed. My bank statements say the year is 112.
5. Re:The Y2K bug was REAL by c0lo · 2012-11-20 09:33 · Score: 1, Insightful
  
  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?
  
  --
  Questions raise, answers kill. Raise questions to stay alive.
6. Re:The Y2K bug was REAL by Cinder6 · 2012-11-20 09:33 · Score: 1
  
  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.
  
  --
  If you can't convince them, convict them.
7. Re:The Y2K bug was REAL by ShanghaiBill · 2012-11-20 09:34 · Score: 4, Interesting
  
  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.
8. Re:The Y2K bug was REAL by Cinder6 · 2012-11-20 09:37 · Score: 2
  
  Not sure why you expect a bank, of all things, would get basic things right...
  
  --
  If you can't convince them, convict them.
9. Re:The Y2K bug was REAL by Bigby · 2012-11-20 09:37 · Score: 1
  
  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.
10. Re:The Y2K bug was REAL by Bigby · 2012-11-20 09:44 · Score: 1
  
  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.
11. Re:The Y2K bug was REAL by Anonymous Coward · 2012-11-20 09:45 · Score: 0
  
  Don't worry, the Y2038 problem will have long prevented us from reach 2156.
12. Re:The Y2K bug was REAL by Anonymous Coward · 2012-11-20 09:48 · Score: 2, Interesting
  
  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.
13. Re:The Y2K bug was REAL by operagost · 2012-11-20 09:49 · Score: 2
  
  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
  
  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.
  
  --
  
  Gamingmuseum.com: Give your 3D accelerator a rest.
14. Re:The Y2K bug was REAL by operagost · 2012-11-20 09:53 · Score: 1
  
  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.
  
  --
  
  Gamingmuseum.com: Give your 3D accelerator a rest.
15. Re:The Y2K bug was REAL by mcrbids · 2012-11-20 09:56 · Score: 1
  
  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.
  
  --
  I have no problem with your religion until you decide it's reason to deprive others of the truth.
16. Re:The Y2K bug was REAL by jamesh · 2012-11-20 09:56 · Score: 1
  
  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.
17. Re:The Y2K bug was REAL by BobNET · 2012-11-20 09:57 · Score: 3, Interesting
  
  We used a single byte to store the offset from 1900 in binary.
  Most TRS-80 operating systems figured 3 bits was enough to store an offset from 1980, so we've already lived through the Y1.988k bug.
18. Re:The Y2K bug was REAL by joaosantos · 2012-11-20 10:01 · Score: 1
  
  My a suggest using a different bank?
19. Re:The Y2K bug was REAL by Carewolf · 2012-11-20 10:10 · Score: 1
  
  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.
20. Re:The Y2K bug was REAL by Vanders · 2012-11-20 10:22 · Score: 1
  
  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.
  
  --
  Syllable : It's an Operating System
21. Re:The Y2K bug was REAL by jjeffries · 2012-11-20 10:49 · Score: 1
  
  I never had my own internal Y2K bug fixed. I keep writing "19112" on paperwork.
22. Re:The Y2K bug was REAL by 0123456 · 2012-11-20 10:50 · Score: 1
  
  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.
23. Re:The Y2K bug was REAL by 19thNervousBreakdown · 2012-11-20 10:57 · Score: 1
  
  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".
  
  --
  <xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
24. Re:The Y2K bug was REAL by Cartotype · 2012-11-20 10:58 · Score: 2
  
  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".
25. Re:The Y2K bug was REAL by Darinbob · 2012-11-20 11:09 · Score: 1
  
  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.")
26. Re:The Y2K bug was REAL by Darinbob · 2012-11-20 11:14 · Score: 1
  
  There are people use a Date type, but then ran into problems when converting back and forth to character types. Silly stuff like "years 0-50 add 2000, years 51-99 add 1900", then using that for birthdates.
  Really, this is where experience matters. I see these problems from junior programmers who've never had the experience of dealing with long range compatibility problems, or who are naive enough to treat library routines as appropriate for all situations, or just not the mindset for thinking ahead about how things can break.
27. Re:The Y2K bug was REAL by brentrad · 2012-11-20 11:17 · Score: 3, Informative
  
  I beg to differ about not experiencing significant problems on 1/1/2000. We had significant issues that caused all our approximately 2000 store servers to repeatedly shut down until we unloaded the offending software.
  
  I was working for Hollywood Video in the Tech Support department (support for the rental stores and all their computer equipment) leading up to and after Y2K, in Wilsonville, Oregon at the corporate office. (Of course this was before their two bankruptcies.) The software development department performed extensive (and probably expensive) testing on every facet of our current in-store software and hardware setup (custom COBOL software running on DOS 5.0 on NetWare 3.1 if you can believe it.) They were even going to scrap NetWare in favor of a brand spanking new Windows NT Remote Desktop-type setup, but we were highly disappointed when NetWare came up with a patch for NetWare 3.X series to make it Y2K compatible, so they scrapped the NT plans. But I digress...
  
  Came in to work on 1/1/2000 a couple hours after midnight (yep they pretty much forced us to come in, and for very little extra pay - I may have been a bit drunk still.) Everything was already chaos: Almost every single store's NetWare server shut itself down at midnight, thinking there was a power outage. And since our stores' computers ran as dumb network-booted terminals to the main server, that means all the computers were down and rentals couldn't be performed except by writing the rentals on paper.
  
  Problem was, in the test lab someone had commented out the UPS backup auto-shutdown software line in the servers' autoexec (or its NetWare equivalent, might have been autoexec.ncf or something.) And yes, I do know who that someone was (wasn't me.) :) So I guess no one thought to test that particular software. So all the servers would boot up, immediately think there was a power outage, and immediately shut themselves off. We did have a manager's station computer in each store that had its own hard drive and could be used in emergencies, and had pcAnywhere and a modem, so we manually dialed into each of our approximately 2000 stores (at 14.4 kbps.) Then we walked a bunch of clueless managers and minimum wage kids through taking the new autoexec we had copied to a floppy on their manager's station (and a bunch of the stores had to run out and buy a box of floppies on New Year's Day) and booting up their servers using the floppy.
  
  I think we got the last few stores up and working by 2 or 3 pm Pacific. And before you say "who rents movies on New Year's Day?" - EVERYONE did. New Year's Day and Christmas Day were two of our biggest movie rental days of the year. People are home with their families, the festivities are over, everyone wants something to do and streaming from the internet didn't really exist yet. What did everyone do? Rent a video or go to a theater. I'm not sure how many tens of thousands of dollars in rentals we lost that day, but I'm sure it was significant.
  
  TL;DR: Just because you didn't hear about any significant losses due to Y2K bugs, doesn't mean they didn't happen. It's not like businesses were eager to admit they screwed up and forgot to test something.
28. Re:The Y2K bug was REAL by rtaylor · 2012-11-20 11:18 · Score: 1
  
  I helped a couple of restaurant owners get through New Years day when their POS systems had stopped functioning as expected.
  The work-around was straight forward; use an earlier year with matching days of the week.
  
  --
  Rod Taylor
29. Re:The Y2K bug was REAL by rduke15 · 2012-11-20 11:19 · Score: 1
  
  Your bank should not let Visual Basic "programmers" touch Perl code.
30. Re:The Y2K bug was REAL by girlinatrainingbra · 2012-11-20 11:20 · Score: 3, Interesting
  
  Actually, most TRS-80 operating systems didn't even keep TRACK of time. It's the Disk Operating System (LDOS) that you're talking about. The TRS-80 didn't even have a built in clock / timer board / dedicated bits or bytes for knowing the time. And Level I and Level II Basic on it don't ask about the time or save it on the cassette tape system. And neither did the Apple ][+. You had to buy add-in clock boards to keep track of the time.
  Even the IBM PC did not have a real-time clock until the IBM-AT version in 1984. [Thank you wikipedia for prior info]. If you boot up an old IBM machine, one of the first things that the system asks after boot-up is to enter the time and date. [actual info from turning the old computers on in the garage].
31. Re:The Y2K bug was REAL by Crypto+Gnome · 2012-11-20 11:20 · Score: 1
  
  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.
  Because if you accept that the problem was real and the only reason life doesn't suck as badly as predicted is because the fix was real means you are going to have a LOT more trouble sticking your fingers in your ears and chanting LALALALA I CAN'T HEAR YOU whenever people discuss Global Climate Change.
  
  --
  Visit CryptoGnome in his home.
32. Re:The Y2K bug was REAL by NotSanguine · 2012-11-20 11:24 · Score: 1
  
  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.
  I agree. That's why I moved to Somalia. Come on over, the water's fine!
  
  --
  No, no, you're not thinking; you're just being logical. --Niels Bohr
33. Re:The Y2K bug was REAL by Darinbob · 2012-11-20 11:25 · Score: 2
  
  However time_t, whether 32-bit or 64-bit, was intended for file dates. It was not intended for general all purpose date handling. And yet people do this. They use the signed 32-bit time_t for storing birthdays for example. Or the 64-bit time is used without accounting for historical calendar changes.
  And MANY embedded systems out there use a signed 32-bit Unix time (some even with unsigned 32-bit, which is perfectly logical for file creation times). There are even Unixes still running that don't do 64 bit time_t. There are DOS based systems out there still.
34. Re:The Y2K bug was REAL by Anonymous Coward · 2012-11-20 11:31 · Score: 0
  
  Your bank should not let anyone touch Perl code.
35. Re:The Y2K bug was REAL by UltraZelda64 · 2012-11-20 11:34 · Score: 1
  
  Y2K was blown so far out of proportion, I thought it was obvious leading up to the time that nothing was going to happen. Just sensationalist garbage passed on as news to make a few extra quick bucks. Same as the world ending in 2012: Pure bullshit. If anything major did happen, then I would have reconsidered my stance long ago... but it didn't. The problems were for the most part all fixed well before the deadline, and once 2000 hit pretty much every clock struck midnight of the correct year.
  I'm sorry, but I don't fall for the mass hysteria that the news corporations of the world want you to be a part of to increase their own profits and audience size. People will get shit done if needed, and the more important it is, the more likely it will get done with plenty of time to spare. All the attention these companies brought to the subject by putting it in the spotlight for their own gains no doubt helped a little bit in the process, but I still believe it was unnecessary and overdone to the point of pure profit-driven scare tactics. It would have been fixed either way, and most likely on time no matter what. It became known quite a bit of time in advance.
36. Re:The Y2K bug was REAL by rk · 2012-11-20 12:21 · Score: 2
  
  Just because you're not punching kids out THIS VERY MINUTE doesn't mean your cost/benefit to the gene pool drops to near zero. Humans in modern societies take 2 decades or more to become self-sustaining, to say nothing of the aid (financial, emotional, or educational) provided by grandparents and then the very act of going to work in the morning, living somewhere and paying property taxes for schools (ideally) educating kids still adds benefit, regardless of whether you have kids of your own or not. And funny thing: People have their own metrics of cost/benefit in any case and in my experience it's not often it's the gene pool at large they're considering when they evaluate that metric.
  But you are right: you cannot be prepared for everything. That's in part why we have insurance: We turn an unpredictable but potentially unbearable cost into a predictable but certain affordable cost, turning over that risk management to people who (we hope!) are better at it than we are. Presumably this is why my flood insurance was a lot more expensive and covered less when I lived in what was basically a swamp 10 miles from the hurricane prone coast than the house I have now in high ground in the desert. :-)
37. Re:The Y2K bug was REAL by Anonymous Coward · 2012-11-20 13:48 · Score: 0
  
  I call this the insurance problem. You can pay for insurance for a lifetime and never collect. And the truth is, you really never want to collect because collecting means that something pretty bad happened.
  However as an emotion, it can feel like a big ripoff if you never collect on your insurance. You spent a lot of money and "got nothing for it".
  What this misses is that insurance quite possibly gave you some emotional assurance against the possibility of disaster. And there's that irreducible issue, what if the insurable event did happen? Would you want insurance or not?
38. Re:The Y2K bug was REAL by Anonymous Coward · 2012-11-20 13:49 · Score: 0
  
  We predicted & remediated bugs that would have run at dates from end of 1999 to 2012 for our clients. Others have reported bugs & loses @ each date we predicted.
  Some bugs were near hidden, some were never noticed as Y2k bugs. Automatic grease dispensers quit @ 1 Y2k date causing expensive machines to fail. I was surprised that bug was recognized as Y2k.
  "the media who over-hype everything so people are growing desensitised" except people that do not watch or read mass media lies.
  Our last predicted date was in 2013, so maybe this is not last year?
39. Re:The Y2K bug was REAL by Dagger2 · 2012-11-20 14:05 · Score: 1
  
  So there will be no overflow until 2156.
  Or 19256, as some of those systems would display that year as.
40. Re:The Y2K bug was REAL by noobermin · 2012-11-20 14:48 · Score: 1
  
  What a damn, insightful comment! Slashdot, there is hope for you yet.
41. Re:The Y2K bug was REAL by Mal-2 · 2012-11-20 15:02 · Score: 1
  
  The PC and PC/XT were very commonly retrofitted with an AST Six Pack or generic equivalent. It was expensive, but still cheaper than buying each function on a separate card (and using six slots, which the PC didn't even have, it had just five). Even then it required running a program at startup to read from the RTC and load it into the motherboard clock. Setting the time on the Six Pack also took an executable, as simply setting the time the normal way didn't write it back to the board.
  
  --
  How is the Riemann zeta function like Trump rallies? Both have an endless number of trivial zeros.
42. Re:The Y2K bug was REAL by StormReaver · 2012-11-20 16:10 · Score: 1
  
  We used a single byte to store the offset from 1900 in binary. So there will be no overflow until 2156.
  The vast, vast majority of software that ran infrastructure was COBOL, and it almost always uses PICture statements, not single bytes, to define dates. Those PIC statements most commonly defined dates using 2-digit years. Stupid and short sighted, yes. But also a very real issue that took gajillions of man hours to fix.
  Y2K disasters would have been very real (not as real as the Press would have had us believe, but very painful) if all that code hadn't been hacked. Note that the problem wasn't actually fixed in a lot of cases. It was just delayed another 70 years or so by using a Y2K window.
43. Re:The Y2K bug was REAL by mellon · 2012-11-20 17:36 · Score: 1
  
  Yeah, it cuts both ways. The fact that nothing happened doesn't mean that the preventative worked. But the fact that nothing happened also doesn't mean that the preventative wasn't needed. It's important to understand why the reasoning is flawed, and not just that it is flawed, or else you wind up falling into different flawed reasoning.
  E.g., the reason people believe the stimulus worked is not that things might have been worse without it, but rather that things _are_ demonstrably worse in places where the government chose austerity instead of stimulus. So, regarding the Patriot act, can you come up with a similar comparison? It's pretty clear that loans are the wrong way to help people afford college, but nobody seems to have the testicular fortitude to replace them with grants.
44. Re:The Y2K bug was REAL by Dr_Barnowl · 2012-11-21 00:07 · Score: 1
  
  I worked on a system processing medical records that used a number of distinct methods of storing dates
  * British 2-digit years : dd-MM-yy
  * British 4-digit years : dd-MM-yyyy
  * American 2-digit years : MM-dd-yy
  * ISO 8601 style : yyyy-MM-dd (this is the correct form for all cases where you have to store the date as text)
  * An integer offset in minutes from a custom epoch value
  The rule I tried to adopt was to always store the date in an unambiguous format, and to present it to the user in whatever format was appropriate. Alas, the system in question only worked properly if you configured the server to be in the British locale, and a surprising number of clients leave their servers in the USA locale when they install the OS. Yes, the code could have been better...
  There are some "special" problems with the date handling in the MS implementation VBScript - like the lovely little bug where if your system is configured for the British locale, the date parsing still thinks it's American, *until* you pass it a date that would be invalid, then it will suddenly consider itself British.
  A brief test demonstrates that it STILL does this....
  ' Save as "test-date.vbs" and double click to run MsgBox(CDate("12-02-1999")) MsgBox(CDate("13-02-1999"))
  Produces two popups proclaiming....
  * "12/2/1999" (so far so good)
  * "2/13/1999" (D'oh!)
  The popups are in the American format, MM/dd/yyyy - despite the British locale. But the String parsing will consider being British, but only if the American worldview doesn't prevail....
45. Re:The Y2K bug was REAL by david_thornley · 2012-11-21 05:02 · Score: 1
  
  The fact is, when we put all our data on 80-column punch cards, we'd use only two columns for the year. It would have been possible to encode it in one EBCDIC column as you say, but the cards were keypunched by women* who wouldn't generally know how to do that, and sometimes spot-verified by office staff who could read a two-digit number much easier than a format putting 256 values into one column. (Not to mention that, if you did too many fancy things, you could conceivably wind up with a lace card that would jam the reader.) You didn't want to add unnecessary columns to a data format, because you did NOT want to have to split information across two cards. It was also easier for COBOL programmers to keep the data in the same format throughout processing, rather than having separate formats (COBOL, at the time, didn't have user-definable functions that could return a value).
  In the early keypunch period, most people weren't expecting the actual programs to last very long, and if they did, they'd be easy to reconvert (programmers were much cheaper than computers, after all, and approximately nobody in business worried about source code retention). This wasn't necessarily bright: the IBM 360 came with IBM 709? emulation so businesses could continue to run old programs, and that could have been a clue.
  Unfortunately, after punch cards faded away, the habit of the two-digit year remained. I saw a LOT of them in the years following, and no cases of a one-byte year (I suspect those programs didn't last).
  
  --
  "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
46. Re:The Y2K bug was REAL by Anonymous Coward · 2012-11-21 06:12 · Score: 0
  
  But the sand will kill you.
47. Re:The Y2K bug was REAL by Anonymous Coward · 2012-11-21 06:17 · Score: 0
  
  CP-6 E00 had this same issue. time stored in a 36-bit word. The solution was to poweroff the system prior to rollover (some time between 88 and 94 i don't remember) and power it back on afterwards.
Those damn Mayan's!!! by Supp0rtLinux · 2012-11-20 09:14 · Score: 1

The Mayan's are up to something sinister what did they know that we don't?
1. Re:Those damn Mayan's!!! by mcgrew · 2012-11-20 09:34 · Score: 1
  
  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!
  
  --
  Free Martian Whores!
2. Re:Those damn Mayan's!!! by Cinder6 · 2012-11-20 09:38 · Score: 1
  
  The Mayan's are. It's a lot like an alot.
  
  --
  If you can't convince them, convict them.
3. Re:Those damn Mayan's!!! by mcgrew · 2012-11-21 03:34 · Score: 1
  
  It's a lot like an alot
  Indeed it is, it's simply ignorance and aliteracy. "Alot" for a lot is more like "loose" instead of "lose" in that it can completely change the meaning of what the writer was trying to convey.
  It shows one's ignorance and lack of reading and lack of education. When the uneducated aliterate comes to a site for nerds, they should be made fun of.
  
  --
  Free Martian Whores!
4. Re:Those damn Mayan's!!! by poofmeisterp · 2012-11-21 06:20 · Score: 1
  
  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!
  Good one, mcgrew. :)
2000 ZERO ZERO by Jeremiah+Cornelius · 2012-11-20 09:16 · Score: 5, Funny

Party's over,
Whoops! Out of time!

--
"Flyin' in just a sweet place,
Never been known to fail..."
Why 2000? by Anonymous Coward · 2012-11-20 09:16 · Score: 0

I wanted to party like it's 1999 :(
1. Re:Why 2000? by aliquis · 2012-11-20 09:31 · Score: 1
  
  Quick! Sell your Nokia stocks! :D
2. Re:Why 2000? by Anonymous Coward · 2012-11-20 10:07 · Score: 0
  
  Any excuse to resurrect a 10 year old joke. YEAH BABY YEAH.
Not a Y2K bug according to TFA by Anonymous Coward · 2012-11-20 09:16 · Score: 1

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.
1. Re:Not a Y2K bug according to TFA by Bigby · 2012-11-20 09:29 · Score: 1
  
  But why did it reset to the year 2000? Why not to epoch: Jan 1 1970? Is 2000 the new epoch?
2. Re:Not a Y2K bug according to TFA by Anonymous Coward · 2012-11-20 09:43 · Score: 1
  
  No idea, but probably not because the "year" field reached "99" and rolled around, which is what a Y2K bug would have looked like.
3. Re:Not a Y2K bug according to TFA by Anonymous Coward · 2012-11-20 12:56 · Score: 0
  
  A lot of software, especially some firmware/BIOS type things, have some rough idea of the date they were programmed in, and will either block or ask for confirmation to set the date earlier. Resetting the time will reset it to that date, because it at least knows it is after the day it was programmed or that field was last updated in the source code.
RTFA by Anonymous Coward · 2012-11-20 09:20 · Score: 2, Funny

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).
1. Re:RTFA by marcosdumay · 2012-11-20 11:48 · Score: 2
  
  alternatively, never reboot your servers
  Or, better. Reboot your servers one at a time, a couple of times a year. That way, when a problem happens (may it be the RTC battery failing, bad init scripts or watever else) you'll catch it in a much more safe way.
  
  --
  Rethinking email
The Y2K bug by geekoid · 2012-11-20 09:23 · Score: 5, Insightful

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

--
The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
1. Re:The Y2K bug by PPH · 2012-11-20 09:27 · Score: 5, Funny
  
  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.
  
  --
  Have gnu, will travel.
2. Re:The Y2K bug by c0lo · 2012-11-20 09:37 · Score: 1
  
  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).
  
  --
  Questions raise, answers kill. Raise questions to stay alive.
3. Re:The Y2K bug by Cinder6 · 2012-11-20 09:40 · Score: 1
  
  I recently saw "2k12" written somewhere. *sigh*
  
  --
  If you can't convince them, convict them.
4. Re:The Y2K bug by ShanghaiBill · 2012-11-20 09:45 · Score: 1
  
  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.
5. Re:The Y2K bug by Bigby · 2012-11-20 09:51 · Score: 1
  
  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.
6. Re:The Y2K bug by jamesh · 2012-11-20 10:01 · Score: 1
  
  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.
7. Re:The Y2K bug by cdrudge · 2012-11-20 10:04 · Score: 1
  
  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).
8. Re:The Y2K bug by Anonymous Coward · 2012-11-20 10:36 · Score: 0
  
  So this would be... NTFU ?
9. Re:The Y2K bug by MobyDisk · 2012-11-20 11:06 · Score: 2
  
  Wait, isn't Y2K going to happen in 2048?
10. Re:The Y2K bug by marcosdumay · 2012-11-20 11:49 · Score: 1
  
  But year 2120 is still far away...
  
  --
  Rethinking email
11. Re:The Y2K bug by Anonymous Coward · 2012-11-20 12:59 · Score: 0
  
  Can't we just leave out the 2? It's strongly implied enough, I think. Just call it the "YK problem" because everyone knows which millennium we're talking about.
12. Re:The Y2K bug by Anonymous Coward · 2012-11-20 12:59 · Score: 0
  
  I see stuff like that all the time on resistors. A 2k12 resistor is not to be confused with a 2r12 resistor.
13. Re:The Y2K bug by Anonymous Coward · 2012-11-20 13:01 · Score: 0
  
  I certainly had problems with licensing servers for several high end engineering simulation software suites. If it was "planned obsolescence" they must have planned 10+ years in advanced (no need to upgrade such software when it worked as needed and already interfaced with inhouse software, so UI improvements for those suites didn't matter to us).
14. Re:The Y2K bug by Rich0 · 2012-11-20 14:27 · Score: 1
  
  Believe it or not I still see applications being developed with reliance on two-digit years.
  People say that Y2K was the result of computers not having enough memory to store 4 digits. That might have been true once upon a time for a few systems, but for the most part it is due to laziness. Ugh, can't you shorten that field? And so on...
15. Re:The Y2K bug by PPH · 2012-11-20 17:12 · Score: 1
  
  I can imagine Professor Farnsworth muttering darkly about those morons back in the 21st century and all their stupid shortcuts.
  
  --
  Have gnu, will travel.
16. Re:The Y2K bug by PPH · 2012-11-21 04:34 · Score: 1
  
  I don't see either of those. The printing is too small.
  Now get off my lawn, kid!
  
  --
  Have gnu, will travel.
17. Re:The Y2K bug by poofmeisterp · 2012-11-21 06:24 · Score: 1
  
  did happen. The Y2K disaster did not thanks to a lot of money and a lot of people working to fix the bug.
  It was waiting... in the dark... all of these years it was conspiring, planning, waiting for the moment to lash out against all of those damn people that didn't thank it for not crushing their dreams on 1/1/2000@00:00:00. Mwahahahaha!
Properly configured hosts not impacted by jaredmauch · 2012-11-20 09:28 · Score: 5, Informative

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 for help to correct your NTP setup.
1. Re:Properly configured hosts not impacted by Anonymous Coward · 2012-11-20 09:54 · Score: 0
  
  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.
2. Re:Properly configured hosts not impacted by operagost · 2012-11-20 09:54 · Score: 1
  
  If you saw this problem, consider properly setting your sanity interval.
  
  --
  
  Gamingmuseum.com: Give your 3D accelerator a rest.
3. Re:Properly configured hosts not impacted by Anonymous Coward · 2012-11-20 10:05 · Score: 1
  
  So all Microsoft PCs/servers before 2008 version are broken: http://support.microsoft.com/kb/884776
4. Re:Properly configured hosts not impacted by Anonymous Coward · 2012-11-20 10:33 · Score: 0
  
  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.
5. Re: Properly configured hosts not impacted by Anonymous Coward · 2012-11-20 10:45 · Score: 0
  
  Nothing new about that.
6. Re:Properly configured hosts not impacted by Just+Some+Guy · 2012-11-20 10:50 · Score: 1
  
  What does that have to do with NTP?
  
  --
  Dewey, what part of this looks like authorities should be involved?
7. Re:Properly configured hosts not impacted by Anonymous Coward · 2012-11-20 11:03 · Score: 0
  
  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 ...
8. Re:Properly configured hosts not impacted by Anonymous Coward · 2012-11-20 11:20 · Score: 0
  
  Yes. It's not like the NTP RFC is a mystery.
RIP Charles M. Schulz by Ol+Biscuitbarrel · 2012-11-20 09:28 · Score: 2

Poor Elián González! At least I was able to get ILOVEYOU off of my Gateway. Have you checked out Dora the Explorer?
1. Re:RIP Charles M. Schulz by operagost · 2012-11-20 10:01 · Score: 1
  
  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?
  
  --
  
  Gamingmuseum.com: Give your 3D accelerator a rest.
2. Re:RIP Charles M. Schulz by Darinbob · 2012-11-20 11:38 · Score: 1
  
  I predict peace in our times. At least in Europe where the interconnection of treaties will stay the use of arms.
3. Re:RIP Charles M. Schulz by Ol+Biscuitbarrel · 2012-11-20 13:02 · Score: 1
  
  And we can document the whole thing in this newfangled Library of Congress. Have you chanced to peruse Volta's description of his proposed electrochemical pile?
That's What Happens... by Epicaxia · 2012-11-20 09:29 · Score: 1

...when you forget to put the correct cover on your TPS report.
But did it skew the pool ? by SimplexBang · 2012-11-20 09:32 · Score: 2

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

--
Avoid your fears , or wonder at the past
My work was effected by bufke · 2012-11-20 09:44 · Score: 2

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.
1. Re:My work was effected by Anonymous Coward · 2012-11-20 10:10 · Score: 0
  
  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)
2. Re:My work was effected by Capt.DrumkenBum · 2012-11-20 10:11 · Score: 1
  
  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.
  
  --
  If I were God, wouldn't I protect my churches from acts of me?
Terminology... by tilante · 2012-11-20 09:56 · Score: 1

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.)
No Warning?! by organgtool · 2012-11-20 10:07 · Score: 2

Why didn't you warn us about this time-based bug, John Titor?!
1. Re:No Warning?! by Anonymous Coward · 2012-11-20 14:41 · Score: 0
  
  Just blame it on CERN
This happened to me in 1999 by MichaelSmith · 2012-11-20 10:14 · Score: 2

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.

--
http://michaelsmith.id.au
and the 2038 bug as well as the Year 2042 bug by Joe_Dragon · 2012-11-20 10:34 · Score: 2

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.
1. Re:and the 2038 bug as well as the Year 2042 bug by danomac · 2012-11-20 12:16 · Score: 1
  
  Crap. I never even thought of that.
  Hah! I'll be eligible for retirement just before then! I don't care anymore.
What is this? by Anonymous Coward · 2012-11-20 11:13 · Score: 0

I've looked all over my machine. I can search through every file Linux has, an nowhere is there any file with the words "HKEY_LOCAL_MACHINE" anywhere! Oh and my time hasn't slipped a millisecond. I have an atomic clock (ok a clock that syncs via radio) to atomic clocks (that would make it a stratum 1 source), several times per hour, and when I compare the computer against the clock, the difference is nanoseconds. If the time is critical, you could upgrade to a machine like mine (my timing is perfect).
The Worst Part about the Y2K bug by Crypto+Gnome · 2012-11-20 11:29 · Score: 2

Was not the bug. Nor was it The Fix(ing/es/etc).

It was THE MONEY.

A large part of "LALALALA I CAN'T HEAR YOU" came from arguments which essentially boil down to "but if that's actually true, then fixing it would cost LOTS OF MONEY".

Whoever said HISTORY NEVER REPEATS is a complete moron.

These days s/Y2K bug/Global Warming/ and the situation is EXACTLY THE SAME.

Lots of industries pushing for FLAT OUT DENIAL mainly because of attitudes which amount to not much more than "but if that's actually true, then fixing it would cost LOTS OF MONEY".

Insert here well documented evidence that THE TOBACCO INDUSTRY knew, many many may ears ago that smoking tobacco was (a) bad for you and (b) addictive.

Big Business KNOWS perfectly well that we're pretty much up Fitz Creek without a paddle (or even a canoe) but THEY DON'T CARE as long as they make lots of money TODAY.

Show me one CEO where their bonuses/etc are indexed against ANYTHING more than the next 1-5 years of profit.

An environmental (and therefore economic) CATASTROPHE that will occur no sooner than 10 years from now is akin to the heat-death-of-the-universe, we ALL know it's coming - but NOBODY CARES.

--
Visit CryptoGnome in his home.
How is this possible? by WaffleMonster · 2012-11-20 12:03 · Score: 1

I distinctly remember on multiple occassions feeling irked by what I assumed were tinfoil hat wearing fools who required you to get the time kind of sort of right first before clocks would sync up from an external time source...especially within windows.
I could swear windows and the standard unix ntp systems explicitly check for and do not allow such shenanigans...yet this happened and as I hear from a few sources real systems were effected... Maybe there is some nuance with stratums or something which come into play in this equation...
Its just if you would have asked me if this could happen prior to today I would have said "NO" without any reservation. I'm an idiot.
1. Re:How is this possible? by Lehk228 · 2012-11-20 16:30 · Score: 1
  
  other people who, like yourself, were irked about having to get the time close before clocks would synch up, overriding the sanity check
  
  --
  Snowden and Manning are heroes.
my phone went a bit mad on Sunday by Hognoxious · 2012-11-20 12:24 · Score: 1

My phone, for no apparent reason, reset the date to (forgot the day) of March 2011 on Sunday. It's never done anything like that before.

--
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Is this it? by DFurno2003 · 2012-11-20 12:52 · Score: 0

The mayan calendar ends when the computers all revert to the year 2000 and get stuck in the year 2000 glitch?
Time bugs do happen by laffer1 · 2012-11-20 14:59 · Score: 1

At my last employer, they had the brilliant idea to use 111111 as infinity for time in their database. When 2011-11-11 happened, it was very ugly. Some of the software had been fixed AFTER to use 2911-11-11 as the new infinity date, but not all of it. I was still fixing software when I left in October.
My suggestion to make the field NULL didn't go over well. They couldn't figure out how to represent NULL in their C programs that accessed Ingres. :)

--
MidnightBSD: The BSD for Everyone
Those affected were mostly following instructions by jthill · 2012-11-20 17:05 · Score: 2

A large part of NTP's sophistication lies in its ability to identify falsetickers/truechimers among multiple candidate sources. NTP is built to survive failures like this, but Microsoft apparently doesn't bother telling its Active Directory customers -- it actually instructs them to single-source their clocks.

--
As always, all IMO. Insert "I think" everywhere grammatically possible.
better solution by d3matt · 2012-11-21 03:05 · Score: 1

If you really care about accuracy in your data center, use a GPS or CDMA source for time sync. If you're paranoid, get an atomic clock as well for comparison.

--
I am d3matt
Why do people thin Y2K didn't happen? by Agent0013 · 2012-11-21 03:23 · Score: 1

I was there! I saw the Y2K things going wrong. I don't understand the people who say that nothing happened on that day. I experienced power outages in a dark underground bar. Then when things came back online, the registers would not work for the rest of the night. That's Y2K, right there! Plus, I'm sure glad that people put in the effort to fix the really bad things that could have happened.

--

-- ssoorrrryy,, dduupplleexx sswwiittcchh oonn.. -Quote found on actual fortune cookie.
So, um, party likes it's 1999? by Anonymous Coward · 2012-11-26 20:14 · Score: 0

If only for a short moment...