Are you ready for... 2038?

[GlitchyZorua]

2038. The year that marks the end for 32-bit operating systems. Are you ready for it? Because its gonna be the new Y2K!

Remember the Y2K problem? All hands were on deck! If you were buying a computer (at least, in best buy) in the year 1999, you would notice that there were these stickers all over place! tell you to turn off your computer at the end of the year 1999, i suppose this was to contain the damage caused by the Y2K crisis? 

The Y2K problem was pretty fascinating! (and... chaotic  ), Computers were not ready for the year 2000, and everyone thought the world was gonna end! (thankfully, it didn't...)
However, that's in the past, and we are way, WAY past the year 2000. The year is 2025. Tech has become more advanced (and... dumber?) then before. However, that isn't to say that technology isn't fool proof, (or bug-free), because there are computers that still rely on outdated old software, that is being held together by duct-tape and sticks, and still running a decade old operating system, like Windows XP. If that does sound familiar, that's because some, if not, most, governments are still using Windows XP, Windows 95, and... perhaps Windows 98. That's because the software that they use is critically needed, but the developers decided to stop working on it a long time ago, which means that they also could not be bothered to make it compatible for newer, more modern operating systems, or even modern architectures like 64-bit.

The problem exists in systems which measure Unix time—the number of seconds elapsed since the Unix epoch (00:00:00 UTC on 1 January 1970)—and store it in a signed 32-bit integer. The data type is only capable of representing integers between −(231) and 231 − 1, meaning the latest time that can be properly encoded is 231 − 1 seconds after epoch (03:14:07 UTC on 19 January 2038). Attempting to increment to the following second (03:14:08) will cause the integer to overflow, setting its value to −(231) which systems will interpret as 231 seconds before epoch (20:45:52 UTC on 13 December 1901). The problem is similar in nature to the year 2000 problem, the difference being the Year 2000 problem had to do with base 10 numbers, whereas the Year 2038 problem involves base 2 numbers.

Analogous storage constraints will be reached in 2106, where systems storing Unix time as an unsigned (rather than signed) 32-bit integer will overflow on 7 February 2106 at 06:28:15 UTC.

Computer systems that use time for critical computations may encounter fatal errors if the year 2038 problem is not addressed. Some applications that use future dates have already encountered the bug.[4][5] The most vulnerable systems are those which are infrequently or never updated, such as legacy and embedded systems. Modern systems and software updates to legacy systems address this problem by using signed 64-bit integers instead of 32-bit integers, which will take 292 billion years to overflow—approximately 21 times the estimated age of the universe.

Source: https://en.wikipedia.org/wiki/Year_2038_problem

From what I understand, is that once the year 2038 hits, computers running 32-bit will start overflowing and reset back to the year 1901, because the binary line will not have enough ones to fit! so it fills the binary with zeros, thus resetting it back to the year... 1901!



So, yeah, thats gonna be a puzzling bug to fix! Perhaps one day they'll find a work around for 32-bit systems! (maybe they will be forced to upgrade to 64-bit...)

Here is some good videos talking about the 2038 bug!

Question for everyone on the forum! What will you do if the year 2038 hits! and what suggestions would you give to survive the nemesis known as the Y2K38 bug?  , or even tips on how you can prepare yourself for the y2k38 crisis!


til next time...

Resources:
https://melonking.net/melon?z=/hidden/2k - Melon's 2K
https://www.timeanddate.com/countdown/generic?iso=20380119T031407&p0=%3A&msg=Unix+2038+Clock+rollover&csz=1&swk=1 - 2038 year count down.

[ThunderPerfectWitchcraft]

I was young back then, but I still can tell you that there was a sort of panic about the Y2K-Bug (called usually "Millenium-Bug" or "-Problem" here). There were newsreels going about it, but in the end, things went out pretty smoothly, with only a few systems being in lock afterwards.

Unix time in 32 bit ints can also affect 64-bit systems, and even software that runs within systems that were basically prepared. I'm pretty sure that it will affect some machines and softwares, especially within commercial- and industrial contexts. User-systems shouldn't encounter many problems, as the problem is well known, and updates are much more easier to roll out (and are much more common) than they were in 1999.

[Melooon]

So while it's a long way off, I do wonder about old code like this forum! Was this forum programed with some sort of 32 bit limit that Im unaware of?

From what I can tell the dates and times on the forum depend on PHP and MySQL ideas of what dates and times are, so I suspect in this case it's totally fine since we use the latest versions of those; however you never know! One thing I leaned the hard way is that this forum cannot support IPv6 in anyway.

I think the main worry for me is how I'll handle dates on old systems; I'll have to come up with an agreed standard, like.. 1980 = 2030 or something - but that totally messes with old files dates. I just powered up my DOS computer and put in what I thought was a blank floppy, but it had a bunch of school educational games dated from the early 80s (or maybe the 2030s?) 

There's a poetic quality to feeling the sand of time following out from underneath the feet of old code and knowing you and code share that in common 

[nobo]

There's a poetic quality to feeling the sand of time following out from underneath the feet of old code and knowing you and code share that in common 

the most beautiful thing i've heard all day.

[Eunice]

In 2038 I'll be (hang on while I take my socks off, I need my toes to count this) 76, if I'm not pushing up daisies. I don't think I'll be particularly bothered by code by then. Besides, we'll probably have had a zombie apocalypse. Or the aliens will have landed.

[brisray]

Hey @Eunice you should have done what I did. When I was 18 I promised myself I was going to live forever. So far, so good.

Y2K was chaotic. I was working for a database management company and we started checking the databases and programs we used around late 1998. The comapny decided to do it because the cost of finding problems and fixing them was lower than the compensation we would have to pay to the comapnies whose data we were processing if we screwed up.

Timing isimportant to computers but measuring dates and times is awkward for them. It's why they use epochs as the time for when to start measuring from. 32bit integers are going to overflow on January 19, 2038, but there's other dates that are going to cause problems.

The epoch of HFS and HFS+ Apple Mac systemshave an epoch time of January 1, 1904 which will end on February 6, 2040, for APFS, that will end on July 21, 2554

Windows uses 64bit integers, but its epoch time started on January 1, 1601, so they are going to have problems in 2184.

The Unix time appears to have alrwady been solved with their next problem year of 2486.

But who knows what computers will be doing by 2184, let alone 2554?

[Slix]

I've heard about this bug before, and it kind of worries me.

The thing is with stuff like this though, is that most older computers that are 32-bit nowadays can barely do much with the internet as it is. So having the correct date in another 15 years will probably not be a huge issue for a lot of things, for a majority of people. There's no reason you can't use an offline machine with the wrong date! I do worry about things like iPods recording Last Played dates and stuff like that, but again, who knows what I'll be doing with computers and older stuff in 15 more years...

Apple released an unexpected bug fix update years ago for iPod touches that had been affected by a FaceTime certificate change, a year after the last iOS 6 update it had prior to that, and they did something similar with a GPS bug that was affecting iOS 10 iPhones, 2 years after the last iOS 10 update prior. So there's always a chance we'll get official fixes for some of these OSes in the future to fix this issue if they are affected!

[crazyroostereye]

Most major Softwares that still have the Bug have it tracked. Or switched to a Unix32 Unsigned INT, where it gets pushed to 2106 like how FreeBSD is doing it.

The Same way Y2K didn't end in Chaos so will Y2K38. Yes older Software might break, but nothing actively Maintained will. In the worst case it will be few Month of a lot of overtime for some poor Devs and Sys Admins.

[Rubbereon]

2038. The year that marks the end for 32-bit operating systems. Are you ready for it? Because its gonna be the new Y2K! [...]

Oooh man, it's nothing against you, but there's lots of scaremongering in the topic opener with some misinfo sprinkled in that my nerdy mind got upset from reading and I felt the need to right the record. 

The Y2K bug was a scare like slenderman or the blair witch, it was based on the misconception at the time that only the last 2 digits were processed and the first 2 digits were static like a value slider that only accounted for every year from 1900 to 2000 so "19" was drawn in black marker on the paper and only the other 2 digis were sliders. Tht's my best analogy.

It never got 'fixed' either, the teal deer to all that is that those who make the computers had the foreknowing to not be doing something this silly and instead they represent the whole year as a number. Computers were made recently and around 1970-1980 they were first commercialized for the general public, so it makes no sense to think this was ever gunna happen.

You got another detail wrong, the bug won't affect every 32-bit machines, for example 32-bit windows machines are not affected and can go on for at least many more years and possibly longer if data bytes for the hours of a day and the days themselves are split in 2, I'm not gonna pretend I'm a windows specialist and I don't know how their dates work, but I know the problem will only affect computers that use the full unix time format, not just the epoch, so it's a problem specific to linux.

Edit1: I read on stackexchange that Windows doesnt even use unix time dates like other folks claim, it uses COBOL time dates. Plus the minimal value for years in a 32-bit windows machine is 1601 which is a 300 years difference from unix's 1901.
https://stackoverflow.com/questions/10849717/what-is-the-significance-of-january-1-1601

Edit2: AS I WAS LOOKING MORE INTO IT, I LEARNED WINDOWS CAN LAST UNTIL 30827!!   
https://www.lieberbiber.de/2017/03/14/a-look-at-the-year-20362038-problems-and-time-proofness-in-various-systems/
FAT is not doing too great, December 31, 2107 is barely better than 2038, stay tuned for the year 2107 problem!


Pee-ess: The teal deer to everything above can be summed into "Linux uses unix timetables and is affected by the 2038 problem while Windows uses COBOL timetables and is completely unaffected. Also Y2K was a meme."


Lastly my closing thoughts, I think linux devs are already trying the fix and extend the unix date format, I don't know the smaller details, but either they wanna turn it from a 32-bit value to a 64-bit value or they wanna change the way it calculastes time for legacy systems.

[crazyroostereye]

The Y2K bug was a scare like slenderman or the blair witch, it was based on the misconception at the time that only the last 2 digits were processed, and the first 2 digits were static like a value slider that only accounted for every year from 1900 to 2000 so "19" was drawn in black marker on the paper and only the other 2 digis were sliders. Tht's my best analogy.

You are also not entirely right, while yes the Media blew it way out of proportion. There were many Softwares and Scripts Business utilized that weren't built using a Standard time Library or similar and utilized the 2 digit method.

Your OS wasn't going to fail, but that small script that a Part-time Programmer made in the 80s that did something vary crucial could. Or all the Softwares that werent updated as OTA (Over the Air) Updates weren't common yet.

An older Colleague who worked at an IT Heavy business during Y2K Crisis told me, that for him it was a lot of Overtime during the Final Months of 99. So they could find all the pieces of Software that had the Bug. And Patching it out. Test everything and so on.

Buisness love pushing everything to last minute

[Melooon]

Its definitely a real issue though  I put a new clock battery in my camcorder and had to reset the date and noticed its maximum date was 2031.. that means all my DV files will overflow backwards if Im still using the camera by then; and that means the wrong dates will transfer over to the computer.. ooph..

[Rubbereon]

That's unfortunate.

Some coders use simpler timetables like the unix time for older and less memory efficient appliances for the same reason coders used to use the unix time on unix and now linux and this is the same issue that comes from it.

If I had to guess why the camcorder can't go above 2031 that would be it.

[crazyroostereye]

Some coders use simpler timetables like the unix time for older and less memory efficient appliances for the same reason coders used to use the unix time on unix and now linux and this is the same issue that comes from it.

This made me think about IoT Devices in specific, how many of those Devices are used in crucial Infrastructure to Monitor Something. Many of those don't get Updated regularly or ever depending on the Device, so these seem to me as the most Affected Systems of this Bug. In my Company we use IoT Devices to Monitor the Pressure for Water Pipes, so what's going to happen if that Bug appears? At best the Monitoring is going to complain and report the Device as Broken. At worst, it will get confused and either Change Parameters it shouldn't or worse.

With further thought this actually more scary than I initially thought.

[AY38910]

HELP MY MAIN LAPTOP IS 32BIT AND RUNS LINUX

Spoiler

Also XP but XP is pretty much useless now

[close]

[brisray]

I think for the most part 64bit computers already have the problem solved. Windows should be able to store dates from 1 January 1601 to 14 September 30828. Unix like machines can use dates from 1 January 1970 to 4 December 292277026596 and Macs from 1 January 2001 ±10,000 years.

The article Year 2038 problem most of what could happen. Older  hardware and software that use dates are going to run into problems.

Software will probably have to be changed. I recently came across an old Y2K problem. Excel and Google Sheets now use the 2029 rule to calculate which century 2-figure years belong to. Many of the dates in the source material for pages like this which contain dates from 1860 to 1914 only used 2-digit years so they all had to be checked before I could publish them.