10 ms·
Year 2038 problem is still alive and well
- cube00 5y agoA friend of mine was telling me how he spun up a consultancy and made enough to retire off the back of Y2K. Must be time to spin up one for Y2K38 and make bank again.
- 14 5y agoDo you remember the mass hysteria and people running out and buying generators and flashlights and survival supplies? My aunt thought it would be the end of the world and bought a bunch of supplies in case everything stopped working.
- ianlevesque 5y agoBetter to be prepared and not need it than…well, you saw the last two years.
- spullara 5y agoIf the worked hadn't been done, that is probably what would have happened.
- doublepg23 5y agoFor sure. It's pretty easy to verify what would happen w.r.t. Y2K - you just change the clock...and things broke. LGR did an excellent video [1] on the subject. [1] https://youtu.be/Xm5OiB3CPxg https://youtu.be/Xm5OiB3CPxg
- eru 5y agoWhat makes you think so? My guess is that there would have been some minor disturbances; bureaucratic snafus about life insurance and so on. But unlikely to be a collapse of society.
- d0gsg0w00f 5y agoMy cheapo generator from Home Depot has Bluetooth so it probably won't work on 2039 /s I think it's so you can monitor the fuel level from inside your RV or something.
- dumbfoundded 5y agoYou should just make the right npm package. You could call it: "probably_correct_time" and it'd just add 137 to the year if it was less than 1937 or so. Then raise some money to fund AI research to decipher if it's about the great depression or something to guess the right year. I joke but honestly someone is going to build this and then get acquired by Grammarly.
- partomniscient 5y agoSome companies used this approach for Y2K, deciding to use a pivot similar to the above to decide whether to prefix 19 or 20 (or 21 or 22). It made the fix easy, but they didn't expand the field size from YY to CCYY, so all kinds of stupid errors await us in the future. I was young at the time, and I did what management told me to do but felt icky about it because I knew it was hugely inferior and they didn't know what they were doing, and I was just a tiny cog in the team doing all the changes, most of which thought it was fine... Left that place long ago. What you recommend is an easy fix, and might work most of the time, but its wrong and will cause infuriating problems, probably making others suffer your past deeds. Just do it properly once, first time.
- dumbfoundded 5y agoI completely agree and it's why I wrote it as a joke. Companies/Tools/Projects that plan to exist beyond 2038 should just migrate their code.
- SMAAART 5y agoOh no! Y2K all over, this time Y2K38. Incidentally Y2K38.com was registered in 2002.
- dkasper 5y agoConvince me it won't be largely a nothing burger like the Y2K problem? My guess is in 2037 everyone will frantically test their systems and make some patches and life will go on, no?
- nwallin 5y agoDepends. It's going to hit the embedded world pretty hard. It's going to hit the "no need to update the legacy software that still works" enterprise world pretty hard. It's not even going to be a blip on the open software world because 64 bit `time_t` has been the default since the mid 2000s.
- Xylakant 5y agoThe Y2K problem was a nothingburger because legions of people worked to make it one. Still, critical systems failed - for example the system managing the emergency call lines for the Firefighters in Berlin https://www.heise.de/newsticker/meldung/Computer-GAU-Das-Silvesterchaos-bei-der-Berliner-Feuerwehr-25744.html https://www.heise.de/newsticker/meldung/Computer-GAU-Das-Sil...
- pjscott 5y agoThat's the thing about seeing a problem coming and working to fix it before it happens: an adequate reaction looks the same as an overreaction from the outside, and the "lol overreaction" narrative is way more viral.
- niccl 5y agoAnd it's little known that New Zealand/Aotearoa would have run out of accessible petrol on about Jan 3 if things hadn't been fixed A lot of the y2k thing was badly framed and over-hyped by Large Consulting Companies, but it was a real problem
- LorenPechtel 5y agoAnd there were lots of little gotchas from Y2K that actually did manifest when they concerned dates in the future. Nothing spectacular, just wrong answers. "Expired" stuff being thrown away, improper cost projections etc.
- vmception 5y agoCant this just be Epoch 0 and the next one be Epoch 1 and so on? Adding a designation before the number, or date parsers knowing to separate the first or last digit from the rest of the number, meaning that its not just an overflowing large number its two numbers Any undesignated timestamp being part of epoch 0
- jackpirate 5y agoThat's a good solution for future code, but not for past code. For example, lots of past code makes the assumption that current_unix_time+1 second > current_unix_time which won't be true when the wraparound happens.
- kevin_thibedeau 5y agoThis is also a good case for why unsigned integers are useful. Time calculations using delta values are insensitive to a single wraparound event.
- plasticchris 5y agoThis is a common thing in embedded where 1ms ticks mean overflows every few weeks. Makes me wonder if a more resilient system would have such frequent overflows to force people to come to grips with them.
- lmm 5y agoThat's the big problem with leap seconds IME. Every time one happens we find that the fixes for the bugs that happened last time have been undone during the intervening period.
- dzamo_norton 5y agoAlso to be found out there, and which would need attention, is use of 0 as a sentinel if time = 0 // handle missing data case else ... The kind of thing that makes you wonder "what sort of a day was 1 Jan 1970, actually?"
- NKosmatos 5y agoAssuming we’re all still alive by 2038 :-) With all these things happening recently and with the further problems due to: climate change, pandemics, energy crisis, global warming, economy problems, conflicts between superpowers and all the rest, forecasting 16 years ahead is a little bit tricky (to put it lightly).
- imoverclocked 5y agoAlmost all, if not all, of the things you list as imminent problems were foreseen before they were imminent.
- echelon 5y agoI don't know about the other problems OP listed, but nuclear annihilation seems more probable now than any time since the cold war. We'd almost forgotten about the problem until recently. A cornered, unhinged, elderly dictator with access to a huge nuclear arsenal does not give me comfort.
- vlovich123 5y agoI’ll put any amount of money down that Putin won’t deploy nuclear force unless Russia’s territory is invaded (this includes anything he’s annexed and claimed as his)
- vba616 5y ago>this includes anything he’s annexed and claimed as his Do you have any thoughts on what/whom will be next?
- vlovich123 5y agoGoing by the Foundations of Geopolitics book which seems to capture the strategy so far pretty well AFAICT, the candidates could be Finland & Mongolia? It's not just about direct annexation. A bulk of the work is in creating an indirect sphere of influence to avoid Germany's problem of having the rest of the world coalesce against them.
- MisterSandman 5y agoAyy, nice to see an OpenRCT devs on here! One of my favourite Open Source projects out there right now.
- nyanpasu64 5y agoUnrelated to the particular Int32x32To64 bug in this post, but Wine suffers from the Year 2038 bug and can't access directories with an access time past 2038 (generally caused by software bugs). This has broken the Wine installations of a few people on the Internet.
- dqpb 5y ago2038 is approximately the Omega point, according to Jürgen Schmidhuber, so this makes sense. https://youtu.be/pGftUCTqaGg https://youtu.be/pGftUCTqaGg
- sjg007 5y agoHow about a summary rather than a youtube video.
- tyingq 5y agoMysql closed out a long-standing one in January of this year: https://bugs.mysql.com/bug.php?id=12654 https://bugs.mysql.com/bug.php?id=12654
- mackal 5y agoI was just trying to find that bug report to comment on it, should have just read the comments XD
- tyingq 5y agoWhat's kind of funny is that there seems to be a time related bug with the comments on the bug report page. All the timestamps look like [22 Dec 2021 9:43], except the last one, apparently made in 2022, which has a time of 20:22, and the year is missing: [3 Jan 20:22] Maybe it's intentional that the year is omitted for current year, and just a coincidence that the time is 20:22?
- bombcar 5y agoIt's likely the case, but it also goes to show why "cutesy" timestamps are annoying - even the "a few seconds ago" type you get.
- coffeedan 5y agoNow if only they would fix TIMESTAMP: https://dev.mysql.com/worklog/task/?id=1872 https://dev.mysql.com/worklog/task/?id=1872
- toomanydoubts 5y ago>Doubling the data type width gives more room than anyone would ever need – a signed 64-bit time value will not overflow for 292 billion years. This sentence reminds me of "The last question" by Asimov. Well, it's good enough for us, but "humans" 292bi years from now will still have to deal with it.
- anonporridge 5y agoMeh. Even if the transition to a 128 bit time value takes a billion years to roll out, it's no big deal. There's no reason to think it would be drastically more challenging for whatever intelligence to deal with it then than it is now.
- virchau13 5y agoYeah, but they're not going to do it 1 billion years in advance, they'll do it 2 years before :p
- Aeolun 5y agoI’m sure some AI at the time will do a quick lookup of it’s global history to point back to this comment and say “see, they called it”.
- withinboredom 5y agoRoko’s basilisk thanks you for your service.
- zelon88 5y agoIn reality, 1,000 years in the epoch will be just arbitrary. By then they might as well pick a new epoch that isn't 128 bits. What would they need to preserve that they wouldn't be able to emulate or virtualize?
- eyelidlessness 5y ago
- throwthere 5y agoWhy not just store the year as years since 2000-- you'll be good 'til 2099. /s
- zinekeller 5y agoJust listing those using these epoch: Pre-NT Microsoft standards used a 7-bit integer, but only officially from 1980 (0) until 119 (2099). While DOS is officially discontinued, FAT32 is still in extensive use. If we go on the endurance of FAT (in compatibility), we need a new portable file system that must be implemented by 2050. Heck, exFAT suffers from the same problem. MICROSOFT, WHY?! Most RTC chips tends to be centennial - this means current chips only support up to 2099 or 2100 depending on the implementation.
- Dylan16807 5y ago> Most RTC chips tends to be centennial - this means current chips only support up to 2099 or 2100 depending on the implementation. With a reasonable implementation, that's not a problem. A clock doesn't need to handle old values, so you can assume the year is between build_date - 10 and build_date + 90, or something like that. Or at boot assume you're within 50 years of your last filesystem update. Also huh, exFAT added a byte to timestamps to change the resolution from 2 seconds to .01 seconds, but still kept the awkward bit fields from FAT32. Also some implementations break the new byte. Just changing the bit fields to a single number would have pushed the end date to 2250.
- segfaultbuserr 5y agoMy favorite fun fact about Y2K38 is the VMS operating system. > While the native APIs of OpenVMS can support timestamps up to the 31st of July 31086, the C runtime library (CRTL) uses 32-bit integers for time_t. As part of Y2K compliance work that was carried out in 1998, the CRTL was modified to use unsigned 32-bit integers to represent time; extending the range of time_t up to the 7th of February 2106. A Y2K38 problem fixed during the Y2K!
- Piskvorrr 5y agoWell, I'd say "postponed" ;)
- acadapter 5y agoWhy unsigned 32 bits and not 64 bits? This is not a proper fix...
- dspillett 5y agoProbably due to concerns about changing the size of many structs that include time_t values, which could cause a lot of bugs in C code and similar where the size had been assumed. Moving to unsigned types doesn't change the storage requirements.
- _kst_ 5y agoThis "fix" also made it impossible to represent times before 1970. Admittedly that's probably a rare problem, but I can imagine it could have broken something (An interesting tidbit: Since 2018-07-22, a 32-bit signed time_t with an epoch of 1970-01-01 has been able to represent the date of birth of every living human. Chiyo Miyako was born 1901-05-02 and died 2018-07-22 at the age of 117 years, 81 days. 2^31-1 seconds before the epoch was 1901-12-13. Reference: https://en.wikipedia.org/wiki/List_of_the_verified_oldest_people https://en.wikipedia.org/wiki/List_of_the_verified_oldest_pe...)
- belter 5y ago"OpenBSD is one of the first operating systems to be safe from the “Year 2038 Problem”. 64-bit time was introduced in 2013, so you don’t have to worry about the Unix Epoch 32-bit issue." https://why-openbsd.rocks/fact/64bit-time/ https://why-openbsd.rocks/fact/64bit-time/
- doublepg23 5y agoDoes this just break applications expecting 32-bit time? It's certainty one way to do it, but I'm pretty sure this is unacceptable to most kernels.
- mjevans 5y agoIIRC Not if they were using the OS time type. I recall BSD is entirely compiled from a shared repository so the only breaking software would be external applications and possibly saves that have an incompatible timestamp baked into the file format. Anything outside of their 'ports' package repo.
- segfaultbuserr 5y agoYes. OpenBSD famously has an official policy of not providing binary compatibility. You can always break userspace for the benefits of code quality and safety. ABI has changed? No big deal, just recompile. Furthermore, since OpenBSD is an entire operating system, not just a kernel, the project has power to apply technical decisions to userspace, so you have more control to do that at will.
- bravetraveler 5y agoWhile it's handled in XFS (the filesystem/kernel aspect), to this day you have to opt into it when formatting: mkfs.xfs -m bigtime=1 ... I have filesystems from ~2002 still in use - I have a feeling I'm going to run into this when I inevitably forget how they're dragging their feet, lol.
- doublepg23 5y agoI was surprised to see `xfs filesystem being remounted at [dir] supports timestamps until 2038` on a brand new Fedora install recently. Wonder what the hold up is.
- Vogtinator 5y agoThe XFS bigtime feature was "experimental" until 5.15, and is still disabled by default in mkfs.xfs. Filesystems with that enabled can't be mounted by older kernels which don't support it, and until 5.15 that causes a big fat "EXPERIMENTAL big timestamp feature in use. Use at your own risk!" warning.
- bravetraveler 5y agoI've been keeping tabs on that as well, long time Fedora user here. I wish I could tell you! Usually this implies some sort of lacking stability; yet I don't recall any specific warnings when I was researching opting in. There may be some insights on the upstream XFS/Red Hat mailing lists (most of the developers are there, IIRC) I've replaced all of my old XFS filesystems to address this and haven't noticed any problems... but filesystem things can be subtle.
- nixarn 5y agoWe all know how this story goes (if you're old enough). In 2036 we'll send John Titor back in time to help us: https://en.wikipedia.org/wiki/John_Titor https://en.wikipedia.org/wiki/John_Titor.
- tragictrash 5y agoAhh I introduced one of these a few years ago! Can't wait!
- leoedin 5y agoIn the embedded space I'm still seeing plenty of 2038-problematic code being produced today. 32 bit microcontroller + unix timestamps = future problems. I think this will bite us hard - way harder than Y2K (which happened when software was far less prevalent). There must be millions or even billions of embedded devices out there which are susceptible to this problem - the only real question is how badly they'll fail.
- jamjamjamjamjam 5y agoOh definitely. How long did python3 take? We’re still on ipv4. But lets chill. In 2038 I should be retired but I’ll return from my retirement and make bank
- avnigo 5y agoI can picture it now, coming out of retirement for one last job[0]. Not kidding, that's a movie I'd watch. [0]: https://tvtropes.org/pmwiki/pmwiki.php/Main/OneLastJob https://tvtropes.org/pmwiki/pmwiki.php/Main/OneLastJob
- slowhand09 5y agoSimilar mistakes being made today on different scales. For instance, 3G cellular service is being removed in many places to free bandwith for 5G services. My 2015 automobile has a 3G cellular modem embedded for several services including on-the-air updates. So backwards steps my include plugging in a USB card if updates are needed.