• LCrawford (unregistered)

    How about party like it's 2019? Still dealing with reports that fail every 10 years because of the rollover from 9>0.

    (A side effect of encoding the date as D-WW-Y in the final product)

  • (nodebb)

    Did they test the electronic toilet tubs and coffee makers?

  • Murray (unregistered)

    So they avoided the outage on the 1st of January but had it on the 29th instead. What did they gain by this?

  • Just a Dev (unregistered) in reply to Murray

    People most likely weren't fired...a better alternative.

  • ooOOooGa (unregistered)

    I'm still rather confused by this article. What parts of the building are checking dates? Certainly not the wires and circuit breakers. Power meters from the late '90s also weren't checking dates.

    So what would be causing the power to stop flowing in the building? Especially something that would be listening to their on-site personally-owned NTP server?

  • Andrew (unregistered)

    I really enjoyed this article. I remember well that time. In 1999, I wasn't yet a programmer. I was still working as a network engineer (CNE, LOL, I loved NetWare). I was hired in September of that year and was promptly given the task of researching what we needed for ourselves and our customers to avoid the Y2K-bug. We were a small company, ~10 people, and supported other companies, mostly law firms, in upstate NY. Anyway, I cannot claim sole credit as we all worked hard, but come Jan. 1, 2000, none of our customers went dark. In truth, I completely agree that the apocalypse was avoided because many, many people worked a lot of hard time to avoid catastrophe. It's a shame that "the world" didn't exactly understand.

    You know, I've wondered from time to time, did VW reintroduce the beetle (bug) in 1998 to capitalize on Y2K?

  • Remington Smithington (unregistered) in reply to LCrawford

    Our program has some sort of odd programs printing barcode fonts after the leap year. The thing is most of the support team has turned over several times since the last leap year day and won't know what to expect.

  • Russell Judge (google)

    A company I worked for had a rather unique solution to the Y2K issue. I started there a few years later, so got to see the ramifications of it.

    With all date fields 6 digits long, and date fields proliferating the system to a massive degree, they decided to keep the dates as 6 digits long. Normally, under this situation, a windowing algorithm would be used, but this company solved the problem without windowing by using the alphabet to represent the decade. While 991231 represented December 31, 1999, A00101 represented January 1, 2000. B00517 represented May 17, 2010, and so on. So would joke about at least we'd all be dead by the time the problem came around again on December 31, 2259 (Z91231). I guess there's always the lowercase letters.

  • K. (unregistered) in reply to Russell Judge

    Thats... a surprisingly good solution, given the WTF premises.

    This message was transported back in time from ^90401

  • Dave (unregistered) in reply to Russell Judge

    Windowing worked in some scenarios. Less well in others. One life insurer I happened to be aware of had active records for people born in the early 19th century - survivor benefits paid to a long-lived child born late to the original pensioner - and people born in Dec 1999. They were already using four digits for dob, of course, because they needed to tell the difference between e.g. 1880 and 1980 long before y2k. But it illustrates how even apparently obvious windows like no-one living to 150 don't work in all cases.

  • (nodebb)

    Future WTF: It will occur at 2038-01-19T03:14:08Z when the signed 32-bit UNIX timestamp value rolls over from 2,147,483,647 to -2,147,483,648.

    The Internet of Things may well suddenly become the Internet of Bricks. Yeah. Including elevator controllers, avionics, autonomous vehicles ....

  • eric bloedow (unregistered)

    reminds me of a gag in an online comic: they lost power during their Y2K test, but all they had to do to recover was reset a circuit-breaker...and IT only tripped because they had EVERYTHING turned on at once!

  • ipguru (unregistered) in reply to Russell Judge

    hexideximal year numbers for the win (although if implemented correctly they would go to 99-9a & then max out at zz

  • ipguru (unregistered)

    Ahh now I see why A0- Z9 no other yars have used hex digits in the unitx column & it would f**k up counting to start using them now

  • T.T.O. (unregistered)

    Reminded me of this: http://www.qdb.us/309051

  • sizer99 (google)

    I'm quite amused (and saddened) at the number of Y2K20 failures we've been seeing this week. Nobody ever learns from history.

  • SergeS (unregistered)

    Scary thing, that 2038 is just 18 years away - it seemed a lot more distant few years ago ...

  • (nodebb) in reply to Russell Judge

    Reminds me of my solution to having to change my password once a month, and I cannot reuse any of the previous 12 passwords; I use the same password prefixed with a different special char every month. The problem is that some of the systems I need to login do not use single sign on from LDAP, and they want me to change the password periodically on a different schedule - some every month, some every 90 days.

  • (nodebb) in reply to Russell Judge

    With all date fields 6 digits long, and date fields proliferating the system to a massive degree, they decided to keep the dates as 6 digits long. Normally, under this situation, a windowing algorithm would be used,

    Like "assume that 2-digit years are within the window of (say) 1930-2029, which we may or may not remember to update before 2030 hits"?

    but this company solved the problem without windowing by using the alphabet to represent the decade. While 991231 represented December 31, 1999, A00101 represented January 1, 2000. B00517 represented May 17, 2010, and so on. So would joke about at least we'd all be dead by the time the problem came around again on December 31, 2259 (Z91231). I guess there's always the lowercase letters.

    That's nothing, I cut my teeth on a similar system that converted from "991231" to "?/1231", basically using CHR(32) through CHR(95) to represent 0 through 63: "?/" = CHR(63) + CHR(47) -> (63-32) * 64 + (47-32) = 1999. Covers all years from 0 through 4095. Technically "00" through "99" are ambiguous, but not very ("99" in the base-64 method equates to the year 1625).

    They did convert to YYYYMMDD in later versions, but there are probably still some legacy modules / custom add-ons using the base-64 method.

  • (nodebb)

    The lost power and nothing electrical working was a premise of a book I received as a gift - basically electricity stopped working countrywide (it was set in Czechia, asmall European country). Soon after it happened, the interior affairs ministry recruited every cyclist in the capital as messengers and such. Interesting read.

    Addendum 2020-01-07 15:19: It was a sci-fi book, didn’t actually happen. But still, interesting thought experiment.

  • Hasseman (unregistered)


  • Chakat Firepaw (unregistered) in reply to Murray

    They gained:

    The failure occurring when they were ready to deal with a failure, under circumstances where they could easily rectify the problem by ending the test, and before any sources of outside manpower might be swamped by other companies with similar problems and no rollback option.

  • Anonymous (unregistered) in reply to Developer_Dude

    Instead of changing the password when the systems forces a password change I just change my passwords on all the systems that have this requirement every month on the same day. Put a reminder in my todo list. Passwords all are generated passwords that are stored in a password manager of course.

  • DanK (unregistered) in reply to Murray

    It was planned this way. It sounds like they did not expect problems, but they were prepared for them. Everyone was on site and the issue could be resolved.

    In ‘99, a lot of people did not have cell phones, and on new year’s eve most people are partying anyway. It would have been waaaay more difficult to resolve this issue on the 1st of January.

  • JJ (unregistered) in reply to OllieJones

    Right. IMHO, this should've happened to more companies, and a few planes should've fallen out of the sky. Then, maybe, people would've taken Y2K38 seriously despite the lack of a catchy name. Now it's too late.

    Non-compliant hardware, firmware, software, embedded systems. Dead languages (COBOL, mostly). To fix or replace all of this, we should have started in Y2k.

  • Worf (unregistered) in reply to Murray

    Well, they knew all their IT systems were updated, but their building systems weren't. And they managed to pull it off a day before rather than on NYE and in a half-drunken state.

    And since they knew to expect problems, they were in a mode to debug such.

    They were testing to make sure their Y2K prep was done. As far as they knew it was, but when they went to test it, it failed miserably, but now they had a chance to fix it (albeit only a day, but it's a day more than if they just blindly went forward). Not testing their stuff would be like committing to production just because it compiled, after all. (And there's always some small thing or other that gets overlooked or forgotten about, so you should test that out too...).

  • (nodebb)

    The first instance of the "Y2K" problem appeared in January, 1970, when programs to calculate amortization schedules for 30 year mortgages didn't always work properly. I was working in IT from the early 1990s on, and we'd done some mitigation. I live in California. As the clocks ticked forward and first Australia, then Japan, then Europe, then the East Coast rolled into the year 2000 and NOTHING HAPPENED, I was confident that the Y2K problem had been largely averted.

    But the year 2000 was a presidential election year, and one of the candidates had "claimed" to have invented the internet. His campaign web site had the only really obvious Y2K failure I saw all night, because his site had the date as "1/1/19100".

  • Fernando (unregistered) in reply to ipguru

    No, then the units place would be decimal in some circumstances and hexadecimal in others (so 89 does not roll over to 8A). This solution is correct: the "tens" place is hexadecimal and the units place is decimal.

  • (nodebb) in reply to K.

    This message was transported back in time from ^90401

    Reminds me of one of the games we had on our old 8-bit micro back in the 80s. The score field only had 5 digits. If you got more than 99999 points, the first digit would become a jumbled mess in the game (because it had a lookup table in the code for how to draw each digit in graphics mode, and it ran off the end into other data), but at the end of the game it printed out the score in text mode and you could see that the first digit just continued up the ASCII table from 9. I used to be able to get it up to around J-M, from memory.

  • Guest (unregistered) in reply to OllieJones

    From what I read the internet of bricks is happening now, due compaines going out of business and appliances that are phoning home. I have an old colour TV set built in the '90s still working perfectly. Shows the time of day from teletext signal that the digital degoder generates and has to control all the system an 8 bit controller with a mask ROM. Smart LCD TV sets made by the same manufacturer after the 2000 have the problem that youtube and other smart providers have modified the protocols and even if the control program is on a flash chip and there are upgrading options, the manufacturer doesn't care.

  • WTFguy (unregistered)

    On a serious note, here's a blog entry by a guy who was (is?) a VP-level tech exec at AWS.


    He talks about an actual IT center power failure where the various building systems were just smart enough to panic at a false indication and fail both the main power and the backup power. Oops.

  • Neveralull (unregistered)

    There were various Y2K solutions that only kicked the problem into the future, but a different future date for each solution. There are other date related bugs yet to manifest, for example the coming Unix time stamp rollover. I keep reading or hearing people say that the Y2K bug never happened, and so the world will ignore future bugs of this type.

  • Lőrinczy, Zsigmond (github) in reply to Russell Judge

    (You'd be careful with your database: 'A' might come before or after '0', depending on settings like 'NLS_SORT')

  • (nodebb)

    Fun fact: a webradio I used to regularly listen to is down since the start of the year… because the broadcasting software they use doesn't like 2020.

  • (nodebb) in reply to Scarlet_Manuka

    Early versions of the arcade game "Indiana Jones and the Temple of Doom" had this bug, both for the score, which was limited to six digits, and the number of lives, which was a single digit.

    This meant that on the very few occasions that I acquired 10 of the 11 possible lives it would display as :. Also on one occasion I managed to score over 3 million which presumably displayed as M31,000 or some such during play. (The high score table was however unaffected.)

    Sadly the version on the Internet Archive doesn't have the score bug. (I don't know about the lives bug, since I'm not as good at the game as I used to be.)

  • Some Ed (unregistered) in reply to ooOOooGa

    The smart power devices that the company I was working for during one of my Y2K gigs tracked the date, and would fail when it turned over to 2000.

    What strikes me as odd is that they changed the date on these things when they were an oversight in prior work. That said, the company where one of my coworkers encountered that device did its version of that Y2K test in 1998. They basically declared an extended Christmas Eve to New Years holiday for everyone not in IT or Maintenance,. Everyone in IT or Maintenance who was not taking vacation at that time would get however many days off they didn't need to fix things, plus a bonus week of vacation to be used later that year. And they managed to change the dates on four different devices that "nobody" remembered about.

    Granted, that was their first test that involved more than 10% of IT plus Maintenance, and it involved nearly half, because a lot of people thought that it'd be basically getting the time off anyway plus a bonus week.

    To be fair, they weren't far from wrong, they just got to celebrate Christmas on Sunday instead of Friday. It probably would've been quite a bit worse, except those smart power devices were part of the testing that happened before I left that place months earlier. I only heard about the Y2K pre-drill results because I still had friends who worked (in IT) there.

Leave a comment on “Y-Ok”

Log In or post as a guest

Replying to comment #:

« Return to Article