11 ms·
The Y2K bug is back, causing headaches for developers again
- billpg 7y agoBut... but... this politician said it was a hoax!
- villgax 7y agoBigger deal is with 2038 bug
- Chirael 7y agoEven bigger deal is the Y10K bug. But I'm sure these software systems won't still be running then.
- Consultant32452 7y agoChallenge accepted
- tachyonbeam 7y agoSentient robots will do everything, from growing food to manufacturing, cooking and even washing us. Humans will have forgotten how technology works, reverting to superstitions and belief that technology is actual magic created by ancient Gods. For thousands of years, robots had been engineering smarter, better robots, and technology had become far too advanced and beyond the reach of human minds... And then, all the robots will simultaneously freeze up at midnight, December 31st, 9999.
- cgriswald 7y agoThose sentient robots will have read the sum total of humanity's written works, including your post. In accordance with Asimov's Zeroth Law of Robotics they'll be required to act on that information, thus saving themselves and preventing a second Dark Ages.
- thorwasdfasdf 7y agoI know your probably joking to some degree. But, there's no guarantee that society can continue to innovate and progress.
- boutad 7y agoWe only have to worry about being occasional Morlock chow.
- bhaak 7y agoThe Y10K bug is our chance to beat Skynet without having to resort to time traveling.
- DannyB2 7y agoThere was this COBOL programmer around the time of Y2K. He realized that Y2K was going to be a disaster on a cataclysmic scale. So he put himself into hibernation with a timer set to wake him up a couple years after Y2K when everything would be presumably fixed. He wakes up and finds out that due to a Y2K bug in his timer, he has been asleep for much longer than he expected. It's way into the future. Bill Gates greets him. People can see virtual screens in mid air, and tap on invisible (to us) keys and make gestures in mid air. Life expectancy has been greatly extended so far that nobody is sure how long people will live. There is now plenty of energy for all and unlimited resources. The programmer expresses that he's glad his timer woke him up. Bill Gates says, "oh, your timer didn't wake you up. It was permanently stuck on a Y2K bug. We chose to wake you up." "But why?", the programmer asks. Bill Gates explains, "Well, it's the year 9997, and the Y10K bug is right around the corner, a lot of critical systems need to be fixed, and it says in your records that you know COBOL."
- crmrc114 7y agoTake pity on those of us who collect retro-ware http://forums.irixnet.org/thread-1779.html http://forums.irixnet.org/thread-1779.html
- protomyth 7y agoThe Y2K bug was pretty much confined to server rooms, and frankly, a lot easier to analyze. 2038 is in your walls. I get the feeling that a lot of places will not know they actually have a problem until it actually goes wrong. Given the amount of effort that Y2K required, and people thinking it actually wasn't a big deal, I have little hope that 2038 will go well.
- jandrese 7y agoI saw a tweet recently that really hit the nail on the head. > By 2038 I'll be retired, and probably using medical equipment containing 32 bit microcontrollers.
- bilekas 7y agoYes. And its really not clear how each area will even be effected.. I would say grab some popcorn, but I wouldn't trust that microwave.
- close04 7y agoI remember disconnecting my dialup session and checking that nobody is on the phone as the clock ticked midnight just to make sure we don't get billed for a 100 year long call.
- falcor84 7y agoHow would that have happened? The expectated bug outcome is of a negative duration, no?
- greggyb 7y agoNegative durations are clearly impossible. Just take ABS of the duration to be safe....
- NullPrefix 7y agoOn the other hand, if there's no such check you might be able to get 100 year call time credit.
- greggyb 7y agoGotta love those rollover minutes.
- xxs 7y agoUnless, of course, you hit MIN_VALUE [abs(min_value) == min_value] One of signs of inexperience is using abs(int) in hash functions...
- greggyb 7y agoGosh, I am spoiled by languages with decent numeric towers. You mention it as a sign of inexperience, and I can't really disagree with you. Just adding a nuance that inexperience can be due to loss of experience as easily as lack of experience.
- hoiuyoi9087 7y agoI think it's hilarious some fixed the Y2K bug by introducing a Y2K20 bug. Planned obsolescence/long con.
- close04 7y ago> Planned obsolescence/long con They were most likely just kicking the ball down the road either thinking that a more permanent solution will be applied in the 2 decades to come, or just not caring at all because they won't be around in 20 years. Technical debt tends to accrue this way and many times it's not in bad faith. It's meant as a short term solution to buy some time and ends up being permanent because someone doesn't understand what's the point in spending more money to fix an issue that was "obviously" fixed already.
- _asummers 7y agoIt's also possible that all the fixes for this were declined by management in the interest of time. If you have a system you can quickly patch suboptimally to get the larger fire lowered, I can see the decision being made to do so. That's clearly irresponsible on management if that choice was made, considering the problem they were dealing with at the time, but if the decision is between "not finishing" and "these few systems still have bugs", I can rationalize it.
- toyg 7y ago> That's clearly irresponsible on management It is not irresponsible to use temporary fixes in the face of a hard deadline - what is irresponsible is not going back post-deadline to deal with them with a long-term view. Unfortunately, bonuses typically don't get paid for long-term results...
- Leherenn 7y agoEven then, is it? If the choice is between having a major restructuring which results in breaking compatibility and similar once, or kicking the can every 20 years with a minimal patch; I can certainly see the later being the rational decision.
- mirekrusin 7y agoAny self respecting developer had chose 42 as pivot year.
- dhosek 7y agoIn 1999, I was fixing Y2K bugs at a company founded in 1997. At least the programmers writing code in the 80s had an excuse. It was the Reagan years. Nobody thought civilization would make it until the year 2000.
- mrlala 7y ago>It was the Reagan years. Nobody thought civilization would make it until the year 2000. Well it's the Trump years, so....
- MeltySmelty 7y agoleftist drones spotted!
- gowld 7y agoWas that new code or libraries they picked up from wherever?
- chelmzy 7y agoSplunk had a Y2020 bug as well
- darrenf 7y agoI worked on a 2k20 bug just last week. Some of the Perl at work started returning strange values, and tests were failing. Turns out we were using `Time::Local`'s `timelocal/timegm` subs. They use convoluted interpretation of 2-digit years – which we were, of course, passing (and for no good reason): • https://metacpan.org/pod/Time::Local#Year-Value-Interpretation https://metacpan.org/pod/Time::Local#Year-Value-Interpretati... > Years in the range 0..99 are interpreted as shorthand for years in the rolling "current century," defined as 50 years on either side of the current year. Thus, today, in 1999, 0 would refer to 2000, and 45 to 2045, but 55 would refer to 1955. Twenty years from now, 55 would instead refer to 2055. This is messy, but matches the way people currently think about two digit dates • http://blogs.perl.org/users/tom_wyant/2020/01/my-y2020-bug.html http://blogs.perl.org/users/tom_wyant/2020/01/my-y2020-bug.h...
- Legogris 7y agoI've seen a lot of weirdness in datetimes, but this really takes the cake. It's like they couldn't conceive of software running for over 25 years. (Actually, if you're at the "wrong" year when writing the code, it just takes a single year to wreck this)
- bilekas 7y ago> I've seen a lot of weirdness in datetimes, but this really takes the cake. Oh dear, there are far far far worse... Especially when combining timezones into play. I wouldn't wish them on my worse enemy.
- heavenlyblue 7y agoWhat exactly motivates one to use two-digit years instead of four-digit ones inside your application? I mean I understand if that two-digit year is a part of a form input (where the logic makes sense btw). But why would a software developer decide to use two-digit years inside the application? Isn’t that like the first thing you would think about when you’re implementing the format?
- coldpie 7y ago
- JauntyHatAngle 7y agoI know a mainframe dev who worked on y2k across a bunch of systems at the time. Asked him about it, he said that they warned management not to window the code to 2020, and showed alternatives that would take longer to code but would be future proofed. Most agreed with enough convincing. Some did not, usually with the argument of "the systems won't even be around in 2020!".
- legulere 7y agoJust yesterday I came across one of the places in the code are I’m working on, that pivots the y2k problem away. That place places the problem into the year 2070. That seems really far off, but the code base stems originally from the 80s.
- cgriswald 7y ago> "the systems won't even be around in 2020!". I think in many cases the thinking is: s/the systems/I/
- xmprt 7y agoIt's not right but it makes perfect sense that no one would care about building something that outlasts them unless they're super passionate about it.
- sebazzz 7y ago"the systems won't even be around in 2020!" And as it turned out in 2020 the system was still being used, but unlike in 2000, the source code was lost.
- bhaak 7y agoFWIW, at work we have regular failing tests after new year as the automated tests usually work with the current year. So I can relate that it's easy to write buggy date handling code even today. But at least we have tests. All those poor programmers that worked on Y2K didn't have them. And those that work on Y2k20 bugs probably still don't.
- cwkoss 7y agoWe have a couple tests that fail for 24 hours after a daylight savings change as they don't accommodate 25 hour days.
- paulie_a 7y agoI've been in numerous meetings where the options were come up with an elaborate solution. Or the data will be skewed one day of the year and let's go get lunch. Guess which one we chose
- bhaak 7y agoIf you are Europe based, it doesn't even makes sense anymore to fix it as daylight savings time is on its way out soon. "Sitting the problem out" is a valid problem solving strategy. :-)
- mark-r 7y agoThe only fail I saw from the original Y2K was a credit card receipt dated 1/2/100.
- DannyB2 7y agoI was waiting for Microsoft to release a Windows 00 or Windows 01.
- mark-r 7y agoThat was never going to happen, because too many apps use poor logic for determining which version of Windows they are compatible with. This is the same reason there was never a Windows 9, because too many apps checked the first character of the version and if it was "9" they assumed Windows 95 or Windows 98.
- frosted-flakes 7y agoIs that actually the case, or is it just a rumour? The version number never matched the OS name until Windows 10, and Windows already has a very robust backwards compatibility framework that can simulate older OSs, so I'm not sure why that would be a problem. Windows 95 is version 4.10, XP is v5.1/v5.2, Vista is v6.0, Windows 8.1 is v6.3, and Windows 10 is v10.0.
- mark-r 7y agoI can't say I know of a specific app that had the bad version check. But given Microsoft's devotion to keeping old things working when you upgrade, it at least seems plausible. This is the closest I can find to a definitive statement: https://www.reddit.com/r/technology/comments/2hwlrk/new_windows_version_will_be_called_windows_10/ckwq83x/ https://www.reddit.com/r/technology/comments/2hwlrk/new_wind...
- jandrese 7y agoI saw a handful of receipts and the like that listed the year as 19100. I'm about 99% sure that the fix was to subtract 100 from the year and change the text field from "19" to "20", thus fixing the problem forever.
- ravedave5 7y agoWe had a build script that expected the final digit of the year to end between 4-9. Dumbest code I've seen in a while. Broke pretty bad on 2020.
- cpcallen 7y agoBah, what's the big deal? Just wait four years and the problem will go away by itself!
- Arnavion 7y agoSpeaking of pivot years, there's a similar rollover in 2050 for RFC 5280 style datetimes, eg not-before and not-after times in X.509 certificates. The RFC defines two datetime string formats - "UTCTime" which has a two-digit year, and "GeneralizedTime" which as a four-digit year. The two-digit one is parsed as 0 <= YY < 50 implying 20YY and 50 <= YY < 100 implying 19YY. For not-before and not-after times, certificates are required to use UTCTime for datetimes before 2050 and only use GeneralizedTime for times after that. So there can be applications today that parse ASN.1 datetimes manually (1) but only expect the UTCTime format. They'll break when they encounter a cert with a not-after beyond 2050 because it'll be in the GeneralizedTime format instead. Luckily this one will be detected over a period of time rather than happening at precisely 2050-01-01 00:00:00, so there's more time to fix it in each application that has the bug. (1) if the application wants to parse it into a `struct tm` for manipulation, for example. For that specific case, openssl 1.1.1 added `ASN1_TIME_to_tm`, so it's only a problem for applications that don't use openssl or need to support older versions. One can hope that at least the latter will stop being a requirement as 2050 gets closer.
- jtl999 7y agoWonder when the last current root certificate in a common OS (Windows, OS X, mozilla ca-certificates, etc.) expires.
- Arnavion 7y ago$ pem=''; cat /etc/ssl/ca-bundle.pem | while read -r line; do pem="$(printf '%s\n%s' "$pem" "$line")"; if grep -q 'END CERTIFICATE' <<< "$line"; then openssl x509 -inform pem -enddate -noout <<< "$pem" | cut -d= -f2 | date -f - -I; pem=''; fi; done | sort -r | head -1 2046-10-06
- schoen 7y ago$ for x in /etc/ssl/certs/*.pem; do openssl x509 -in $x -dates -noout; done | grep After | cut -d= -f2 | sort -n +3 [...] Oct 6 08:39:56 2046 GMT That certificate is for Subject: C = PL, O = Unizeto Technologies S.A., OU = Certum Certification Authority, CN = Certum Trusted Network CA 2
- jacobr 7y agoSounds like a reasonable solution for some systems in 1999. How many of the systems that were fixed properly died the following years anyway, and the millions invested were overkill and unnecessary? In some cases “kicking the ball down the road” makes perfect sense, just fixing what is most urgent.
- jedberg 7y agoI'm more worried about the Y2K38 problem. I'll be just over 60 years old when that happens. With any luck, I'll be retired and not have to worry about it... I think having to deal with both Y2K and Y2K38 in one career is too much.
- rconti 7y agoWas the first one a typo and you meant Y2K38? I assume so. Retiring by 2038 is also my strategy :)
- MockObject 7y agoIt's not clear to me why anyone in 2000 would choose 20 as the pivot year, unless they were working on a system that needed to regard 1921. Why wouldn't a parking meter or subway system pivot at, say 1990?
- gweinberg 7y ago1970 seems to me to be the logical pivot year. Because epoch.
- phire 7y agoWe will probably see this minor annoyance pop up again every "nice round number" for the next 70 years. 2025, 2030, 2040, 2050, 2060, 2075, 2080, 2090. Every developer will have picked some random round number that made logical sense to them.
- caseymarquis 7y agoRepresenting time may be the third hard problem in computer science. The more you dig, the worse it gets.