[HN Gopher] Year 2038 problem is still alive and well
___________________________________________________________________
Year 2038 problem is still alive and well
Author : protomyth
Score : 114 points
Date : 2022-02-27 18:09 UTC (4 hours ago)
(HTM) web link (cookieplmonster.github.io)
(TXT) w3m dump (cookieplmonster.github.io)
| NKosmatos wrote:
| Assuming 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).
| NavinF wrote:
| Most people, even those who self-select to participate in
| discussions about such risks, place a 3% probability of any of
| that killing a large chunk of humanity:
| https://www.metaculus.com/questions/2568/ragnar%25C3%25B6k-s...
| LorenPechtel wrote:
| I committed a 2038 bug probably 25 years ago. A salesman found
| it the hard way fat-fingering a job into the 2060s. You don't
| have to reach the trigger date to set these things off,
| anything that looks to the future can trip them.
|
| (I knew it wouldn't work past 2038, I didn't realize it would
| keep anyone from seeing the production schedule if it contained
| an offending job.)
| imoverclocked wrote:
| Almost all, if not all, of the things you list as imminent
| problems were foreseen before they were imminent.
| echelon wrote:
| I 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 wrote:
| I'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)
| davidmurdoch wrote:
| I recently fixed a 2038 bug in Ethereum simulation software I
| work on.
| vlunkr wrote:
| We've survived all that before. (Well, different kinds of
| climate change)
| vmception wrote:
| Cant 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 wrote:
| That'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 wrote:
| This is also a good case for why unsigned integers are
| useful. Time calculations using delta values are insensitive
| to a single wraparound event.
| __s wrote:
| You might as well just use a 64 bit int if you're going to be
| changing code anyways
|
| But this blog post is about how code which is already using 64
| bit ints can have code which silently truncates. Another case
| of C's loose handling of types, whereas in Rust there would've
| been an explicit cast required (granted, in this case the macro
| expands to having explicit type casts)
| nyanpasu64 wrote:
| Unrelated 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.
| SMAAART wrote:
| Oh no! Y2K all over, this time Y2K38.
|
| Incidentally Y2K38.com was registered in 2002.
| unwind wrote:
| Awesome acronym magic, only 25% larger than the thing it
| "expands" to ...
|
| /s
| sigio wrote:
| Yeah, i regged Y2038.nl a couple of years back as well.... nice
| plan for my retirement ;)
| MisterSandman wrote:
| Ayy, nice to see an OpenRCT devs on here! One of my favourite
| Open Source projects out there right now.
| toomanydoubts wrote:
| >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.
| dqpb wrote:
| 2038 is approximately the Omega point, according to Jurgen
| Schmidhuber, so this makes sense.
|
| https://youtu.be/pGftUCTqaGg
| tyingq wrote:
| Mysql closed out a long-standing one in January of this year:
|
| https://bugs.mysql.com/bug.php?id=12654
| mackal wrote:
| I was just trying to find that bug report to comment on it,
| should have just read the comments XD
| tyingq wrote:
| What'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 wrote:
| It's likely the case, but it also goes to show why "cutesy"
| timestamps are annoying - even the "a few seconds ago" type
| you get.
| dkasper wrote:
| Convince 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?
| snailmailman wrote:
| How many smart lightbulbs, washing machines, thermostats, and
| TVs:
|
| - will have literally anywhere that time is 32-bit
|
| - won't be actively updated, but still in use.
|
| This problem has the potential to break clocks on _so many_
| devices. Some may not be easily updatable.
| Gigachad wrote:
| I have seen stuff breaking already. 2020 caused the firmware
| on my nintendo ds piracy flashcart to stop functioning. Have
| to reset the console date to earlier to get it to start.
| phamilton wrote:
| Embedded systems for sure are going to be problematic. https:
| //github.com/arduino/esp8266/blob/master/tools/sdk/lib...
| says that at least some Arduino/esp8266 installations are
| using a long (which I believe is signed 32 bit) for time_t.
| Xylakant wrote:
| The 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-Sil...
| LorenPechtel wrote:
| And 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.
| niccl wrote:
| And 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
| pjscott wrote:
| That'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.
| siffland wrote:
| You are probably correct. Again people will bet on current
| system not being in use 15 years from now and it is not a
| problem until it is a problem.
|
| On a better note Y2K brought us the movie "Office Space", so
| perhaps Y2K38 will give us another equally awesome movie.
| MeinBlutIstBlau wrote:
| nwallin wrote:
| Depends.
|
| 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.
| peteri wrote:
| There was a lecture given at Gresham college:
|
| https://www.gresham.ac.uk/lectures-and-events/what-really-ha...
|
| Which does have a decent list of failures due to the Y2K issue.
___________________________________________________________________
(page generated 2022-02-27 23:00 UTC)