Correction: AD is "Anno Domini", spent my whole life calling it After Death but I learned something new. Use code "SOG" to save money at www.gfuel.com Check out the newest episode of the podcast: th-cam.com/video/e8A2Rn3YrOw/w-d-xo.html
At my job (I am a firmware engineer) I actually had to inform one of my colleagues that the date variable he was storing the current time in seconds since 1970 on our test firmware was vulnerable to this exact 2038 bug. Our fix was replacing the data with an unsigned 64 bit data variable. Would have been funny though to think it was possible for our firmware to cease communication with the internet because it thought that it was 1901 and all certificates it had were not to be enforced until 100 years had passed.
I remember working on the Y2K issues. It was one of my first jobs. What people don't always know is that for some items, the fix is to assume that if the year value seen is under 70, it assumes it is after the year 2000. For anything above 70, it assumes the date is in the 20th century. I think they simply add 100 somewhere in the date calculation. This means that the system would see a 22 for the year, make it 122, then perform whatever math was needed. I don't remember the 'why' behind this, it may have been an issue with the several decades old mainframes, the COBOL language, or just having to handle so much legacy data. This does mean that if these systems are still running in 40-50 years, they may have problems again. One old programmer said at the time, a lot of programs were designed to stop on 9/9/99, because they thought it was a fun date and the code was written in the 1970's, They never imagined their code would still be in use in 20 years.
This issue will probably not be relevant for these companies, most database engines use expanded date formats. Of course this only applies to their servers and recent apps, embededd apps will most likely fail.
The Y2K bug referred to at 5:45 was because prior to 2000, years were being entered as 2 digits on electronic forms, (4/4/89 for instance), and the internal programming could only accept 2 digits for the years for most programs that businesses were running on. This meant after midnight on the last day of '99, all of the systems would roll back to '00, which would be 1900, or they would simply stop working (due to the internal calculations for ages, expiration dates, dates of renewals, and so on would start producing negative numbers which would throw out errors, with no error messages having been provided for in the programming since they lacked the foresight to do so). So, every program that businesses used not only in the US, but around the world had to be tested to see how they would respond to the date rolling over from 12/31/99 to 1/01/00, and a very high percentage of them had to be updated, with programmers having to go in and inspect and analyze the original code and modify it from 2 digit year fields throughout the entire program to 4 digit year fields, so it would recognize the rollover from 1999 to 2000. As an IT professional, I spent 2 years designing tests for those programs and working with developers to get the bugs out, and then retesting them to legally "certify" that they were "Y2K Ready". There were legal documents involved, and copies of the certified software so we could determine for liability purposes that only certified software was used should a problem happen in a major sector of the economy or healthcare industry should a bug be found after the New Year and cause any of the damage that it possibly could have. It was amazing during the lead up to the year 2000 that the majority of the general public actually thought it was all a hoax... and after the New Year came and went, the majority of people could be found proudly saying "I knew it was all a hoax... so, the world didn't come to an end... nothing happened... 'cause there never was any problem to begin with"... and amazingly it's something I still run into from time to time to this day. The one thing that not one of these individuals that was so proud of not being fooled by the supposed "hoax" ever realized, however, (until it was pointed out to them, that is) was that the entire world went from entering years as 2 digits on forms on their computers prior to the year 2000 to being **required** to enter years as 4 digit dates on their computers for everything after 1/01/2000. It was because of that change, being required to enter years on dates as 4 digits on the vast majority of programs running on computer systems, and all of those programs that previously were coded to accept the year as 2 digits for DOB, Expiration Dates, Renewal Dates, etc. being updated to only accept 4 digits for their "year" fields that a worldwide disaster was averted and lucky for everyone, because of the efforts of an army of IT professionals who worked for years to fix that oversight by earlier programmers that we all breathed a sigh of relief after Midnight on the last day of 1999, and were able to finally say "nothing happened... thank God" due to all of that effort.
true, i also thought it was just another "big scary thing" that was basically blown way out of proportion by the news. then again, at that time i was only 8 years old so i don't really feel too bad about not being able to understand the situation correctly lmao.
Yup. That is why we changed our personal ID number from YYMMDD[-/+]nnn to YYYYMMDD-nnnn, In Sweden. (it used to be that + was for people who were older than 100 years old, and - those under 100 years old.)
Engineers have known about 32-bit limitations for as long as we've had binary, so basically forever. There are some systems that were designed for short-term usage that rely on a single, signed 32-bit epoch but not many that really matter. Old software just needs to be updated, and systems that can't be updated will need to be replaced. Everything important either already has been or will be soon. Windows already uses 64-bit time accumulators, for example. So this isn't going to cause any serious harm to society or computer science. It's kind of alarmist hype like the Y2K scare, and you look old enough to remember Y2K. I was a kid and set my date to midnight of December 31st of 1999 and watched in suspense as nothing happened lol. Microsoft had already addressed the issue way ahead of time. Now this may do some harm to old legacy servers running outdated software, but very few of them are relevant. Any people or companies running important systems have either already dealt with this or will in the next few years.
its mostly a problem in places like airports/train stations and hospitals that are stuck using windows 98/xp and 32 bit computers... if that shit wont be updated we will have a massive downtime for transportation all around the world and there are places in the world were goverment/companies/workers do not care about switching to a newer system
@@0Blueaura ATMs, banking systems, even a lot of military systems are still using WinXP today. Although, I would like to think that crucial systems will be updated before it all comes crashing down.
I don't get how the Y2K was going to be a problem in the first place. Binary numbers can never overflow at 2000. It goes from 1024 to 2048. So how was there any problem??
@@0Blueaura What airports and train stations do you know of that are using Windows 98 or even XP? You can barely use XP at home now because it will freak out when you try to browse the web ... it can't understand modern SSL certificates, for example, and has tons of issues. Not to mention, it's incompatible with a vast number of new APIs and software that are industry standards. Networked computer systems like you see in an airport can be updated as needed, and are already using modern OS versions and hardware. They're not the issue ... updating software is completely possible, and even if the underlying hardware has to remain on a 32-bit architecture we can still fix it. A 32-bit CPU can still _use_ 64-bit integers and do 64-bit arithmetic, it just can't _natively_ index the full range of 64-bit memory addresses and 64-bit values can't be moved or manipulated in a single instruction like 64-bit CPUs do. Instead, they have to do it a bit slower with some extra steps, which only matters for heavy, high-performance computing applications and not in the context of ticking a bit per second. So we could very well continue using 32-bit hardware with upgraded software using 64-bit epochs. We just change the way software interprets the value. Another solution is using a single byte as an additional accumulator. Instead of overflowing the epoch and going to negative numbers, it just increments the byte (we could call the variable "epoch_base") by one and sets a new epoch for the timestamp the last one ran out of bits. So if the epoch_base value is zero it's still pre-2038 time, and if the value is 1 then it's post-2038 and 3:14.08 on that day of 2038 is the new epoch base. Just one byte would allow us to do that 255 times, and it would take until 2106 (late January or February, I think) before it had to be incremented again to 00000010 (2 in decimal) and then it'd be February of 2174 when it goes to 00000011 (3) ... you'd get 68.09 more years each time you increment the epoch_base byte to set a new epoch and go back to zero seconds offset from that date. That solution would last for a total of 17,364.54 years before the byte used for the epoch_base value could overflow itself on the 256th increment, lol. This issue is actually all about embedded and legacy systems that aren't connected to the internet and some legacy servers used to interop with old software. Some of these can't really be updated ... they could, technically, but it's easier to get rid of them and replace them usually. Some older cars, for example, have embedded systems that use this 32-bit epoch timestamp. And you'd surely see some embedded systems and legacy servers at certain factories or in other industrial facilities. Thing is, those are already aging systems and this problem is still 16 years away. Not many would even survive that long without breaking down and needing replacing prior to 2038, as they may _already_ be well over 10 years old in 2022. And how important will 25-year-old cars, for example, be to the world in 2038? How many 30-year-old embedded computer systems will still be running undisturbed that are still of any importance to the stability of society? Probably none ... only some very insignificant ones that are privately owned. Anyone doing important business won't sit idly by and watch affected systems crash in 2038 when they have 16 years to act upon it, even if it's an issue.
@@HeraldOD back then, a lot of systems and servers were storing date times as a string in DDMMYY format, not in a native binary format. And it was really major uncertainty about what would happen between software and remote servers they were relying on when they were getting date time strings like 010100 (January 1st, 2000). Turns out, some software needed to be updated but it wasn't the existential threat people feared it would be. Engineers knew about years in advance and fixed their software to account for it. I'm a professional software engineer, and alarmists like to latch on to things like this to frighten everyone and get attention. When engineers explain a problem like this to people who don't really understand computers, they turn it into a doomsday prophecy and it's really just something we look at as an interesting engineering challenge to fix. There's nothing to worry about ... this problem doesn't exist for most modern systems, and before the 16 years are up the last embedded and legacy systems will be replaced. Binary numbers, FYI, come in fixed sizes. 8-bit values (one byte) are the smallest type, and have a range of 256 (0 to 255). Next is a _short_ integer, a 16-bit (2-byte) value which has a range of 65,535. From there we go to 32-bit integers, with a range of 4,294,967,295 ... 64-bit values, like those native to most modern computers, go to absurdly high values (over 18-quintillion). The more times you double the width the more exponentially and absurdly large the range becomes. The numbers you named like 1024 and 2048 are powers of 2 and are very significant in computer science. You can have values with that many bits or bytes in them, but the max values when converted to decimal usually aren't anywhere near being such nice, even power of 2 numbers like that (256 being an exception). Instead we get those big decimal values like 65,535 and 4.2-billion from increasing the number of bits by powers of 2. We usually express these values in hexadecimal when doing low-level programming because binary and decimal are both unwieldy and cumbersome for notation and math and values are hard to remember. Much easier to remember 0xFF (255) or 0xFFFF (65,535) ... hex digits go from 0 to 9 and then from A to F, with 16 total digits. 0x0F is 15, and then it rolls over to 0x10 (16).
An old school computer programmer I knew bragged about fudging his mileage with analog integer overflow by spinning the odometer with a drill. He was a broke college kid at the time, just looking to save money on his summer vehicle, he wouldn't do it today even if he could.
@@StuartWycliffe that actually worked on some analog systems back in the day. And the sawdust in the transmission really works as a band-aid. It’ll destroy the transmission tho.
5:55 the fear of the y2k bug was that a lot of electronics use the date/year in calculations. So we feared everything would divide by zero and stop working :)
I always feel that it's very important to update your system rather than letting it get to that point in the first place, so here's hoping these issues get solved ahead of time.
@@Skrenja Well obviously it's not always good, but the majority of the time it's usually a good choice, or at the very least has to be done (Like those stupid Online Only games). Though I do feel more steps need to be taken to ensure that it's better more often.
4:06 Some errors. A 32-big signed integer (two's complement) can hold -2^31 to one less than 2^31. UNIX programs using a signed 32-bit integer for these dates, wouldn't wrap around to 0 (4:26) once it goes beyond 2^31-1, it would wrap to -2^31, so a time way, way in the past. Data Labs article about the year 2038 problem summarizes: "The issue with signed integers is that they don’t behave like an automobile’s odometer. When a 5-digit odometer reaches 99 999 miles, and the driver goes one extra mile, the digits “turn over” to 00000. But when a signed integer reaches its maximum value and then gets augmented, it goes back to its lowest possible negative value. Adding 1 more to the maximum value of 2,147,483,647 will cause the integer to wrap around to its minimum value of -2,147,483,647 which represents December 13, 1901, at 8:45:52 PM GMT. Any affected computer will think it traveled back in time."
The Y2K bug was actually similar to the Y10K one. Back in the 1970s and the 1980s, data was a rare ressource, so anything that would allow to save some bits of memory was good to take. And this is why in many systems, years were counted on double digit numbers, not the usual four digit ones. So all these old systems that still used 2 digits for years had to be updated before Y2K was reached or the system would believe it was back in 1900.
A buddy of mine and I had this exact conversation. We're both in IT, him in IT Solutions space, me in Dev & RnD. He and I are both in agreement that it would totally suck to be in the industry taking care of maintenance and legacy systems in the next 20 years. He and I plan to get outta the game by then and switch careers before any of that happens, occasionally popping our heads out to see what people are doing.
Best of luck to you and your friend. IT sucks. Cost center, so the ceiling is usually opaque, and you always feel underappreciated by upper management. You are assigned all the blame and receive none of the accolades, especially in larger companies. Would be fortunate to last another 20 years. (In the private sector) you're far more likely to die from stress or to be replaced by offshore contractors / "automation" before then. Hopefully you guys accrue skills and have the ambition to form your own company. Never going to get the full value of your work while working for someone else.
The way of IT: amass as many certifications and pointless skills to pad out your resume like you're even remotely competent based on the on-paper job requirements. Really though, IT as an industry needs to slow its roll. Business units need to take a chill pill, temper some expectations, and just calm the f*ck down. This artificial rush to be the premiere service/software/language is burning people out crazy fast. What we need is some serious industry-wide consolidations.
I'm a software developer and datetimes are always a pain to deal with. In SQL server and most other databases there are two datetime integer formats. The first top's out as you advise, the second one is a massive value in the future. One thing that also affects this is how tight the precision is, to the millisecond, microsecond, nanosecond or even picosecond, as this all takes up space in memory fitting into 32 or 64bits. As hardware becomes faster, tighter precision will become more necessary which ends up reducing the maximum years into the future we can store.
honestly i dont know why you wouldnt just use a custom number/binary format. like: 10 bits millis 6 bits seconds 6 bits minutes 5/6 bits hours (save space/lazy option) 9/10 bits days and that would give you 32/34 so fit in up to 48/64 for years so one year perfectly fits in a 32 bit if thats your limitation. take another for the years (which isnt accessed as often and can be stored just in mem)
As a programmer starting out of college in 1987 I remember the Y2K bug very well. The simplest way to think of it was that programmers, me included, were lazy and looked for easy ways to do date calculations. At that time we rarely ever used a four digit year, instead we would use 87 to mean 1987. The problem came in 2000 when suddenly the last two digits were 00. The maths suddenly broke, generating a negative number. What you're discussing in this video brings those old memories right back to the forefront. Thanks for the work!
This is the same reason why in WaW and BO1 Zombies become one-shot after round 163 and starts alternating between insta-kill rounds and regular rounds every other round.
I heard about this Y2K bug some time ago and feel a little bit worried about system brick like what you said earlier, but glad you have talked this interesting stuff. I hope this issue get fixed or there is some workaround to fix this small but BIG issue... By the way, love your collaborations with Dark Space GTA too.
I’m old enough to remember I was on call in the military for the Y2K, thinking the whole military communication network could fall down, and yet nothing happened. So I’m pretty sure this issue will be fixed before we reach 2038… if we ever do reach 2038, if you know what I mean ;)
@RCBones yeah Y2K was a letdown because everyone spent a lot of money patching the issue, odds are 2038 will indeed be more of the same, spending a lot of money on an issue, everyone goes about as normal or perhaps even mock those who patched it in the first place. Wild world
@RCBones Well, I'm sure there were a fair share of companies that were too lazy or just not financially equipped to hire the programmers necessary to solve the Y2K programming error in any software they used... and if they were unable to do that and it caused enough problems it could have led to their company closing (assuming they relied heavily on such programs). But I can't name any off the top of my head.
This issue I'm sure can and will be easily fixed with our technology in the next 16 years.. I'm sure a programmer can up the integer counts totality or extend it another 100 years
The issue is more likely that systems that works offline needs to be updated manually and that the owner of these systems may not know about the issue or capable of doing the update themself. Some older systems like Windows XP is not longer maintained by Microsoft, those kind of systems needs to be rebuilt to handle time different by someone with knowledge or updated to a later version of Windows / switched to different OS that is still being maintained. Updating an older system that contains databases and such comes with a risk of loosing data during the time of update or due to corruption of data when the update is done.
I've had a similar issue with my grid-based computational fluid dynamics software lately. I implemented several methods to reduce memory demand, so that larger grid resolution is possible in limited GPU memory. But resolution got so large that the 32-bit unsigned integer index for the grid cells started overflowing in some places. Without going full 64-bit integer (GPUs can't handle 64-bit int on CUDA cores, so there would be slowdown), the limit is now at the full extent that 32-bt allows, 2³² grid points. This is equivalent to 225GB VRAM. Few years left until hardware will surpass that limit, currently the largest GPU has 128GB.
DRM can be patched out and pirates take the DRM out. So you can preserve DRM games even though you "don't own it". The pirates don't, yet they do it anyway.
Depending on how a PSX disc is stored, you could probably be assured it's rot-free for another two decades from now; give or take. Making a backup disc once you suspect rot may be coming soon isn't illegal either: you are fully allowed to rip the ROM off the disc for personal preservation purposes. Now, if you're playing the games on a PC, you can just play the backup disc while the original rots; no problem (the illegal part is the BIOS the emulator requires). If you want to be completely legal, you can disc-swap the backup with the original (the original disc has DRM that the backup won't have because Sony used proprietary-coded CDs to print games) or mod-chip the PSX; both of those are legal, but the latter will void the warranty on a 30+ year old piece of hardware. Finally, as disc-rot becomes more prevalent in the future, we can bet our bottom dollar there will be products that allow us to successfully duplicate the games, DRM and all. It may be expensive, as any super-niche product tends to be, but a market will get catered to. Perhaps Sony will let the PSX BIOS enter the public domain or license it out to a third-party, in which case that PSX emulator becomes completely legal to use. Or maybe Sony will go out of business and take their library down with them, which would mean there won't be anyone to prosecute you for using their BIOS. It would still technically be illegal to emulate the library at that point, but ethically you'd be in the clear because you literally could not pay a company that no longer exists for the "legit" experience. tl;dr - You own it, and you can preserve it. You just have to be creative or willing to spend money; or both.
@@TheKrossRoads now that there's products like the psio or the xstation, it's a lot easier to play games with almost 100% compatibility on a real console. it's not like psx lasers are eternal, sadly, we're going to have to move on to modding sometime.
Blizzard created their own packed time algorithm for WoW's calendar where various measurements of time are all stored in a single 32-bit integer. Only 5 bytes are used for the year and the starting year is 2000, which means 2031 is the end for it.
I wonder if this is still the case. WC3 had similar bug when it was released. It catched my eye recently - Patch 1.03 - Fixed a crash that could occur when the system date was set to > 2038. Maybe they did some similar bugfix to wow too?
Cisco had some software that :- 1. Counted "units of time" exactly like UNIX time. Add 1 every time the "unit of time" has passed. 2. Used "4 milliseconds" as a unit of time instead of the second. 3. Stored the value in a 32bit signed int. This gave it just under 99.5 days before it overflowed. Once it overflowed (to -2^32), all the hardware packet forwarding features still worked, but nothing that talked to the main system CPU would work. The system wouldn't answer pings, all routing protocol sessions to it failed, you couldn't SSH into it or even use the serial console etc ... We had several of these in a lab, and something clearly was still going on. Because after another ~99.5 days when the timer got back from -2^32 to 0, the system just popped back into life again. In a slightly goofy state, but you could ping it again, you could login to again etc ... Cisco's solution though ... reboot these devices every 95 days ...
respect to the fact they just said "screw it, we'll just reset it" but damn hope no other companies decide to take that route. would suck to see every few years another update you'd have to install because of bad computing counting.
Unrelated to the 2038 problem, the company I work for uses a variety of different Unix units to store time from dates to hours to minutes to seconds to microseconds. It is really up to the engineering team's perceived need for time measurements. I always loath having to worry about the correct conversion function to include everytime I need to do time series data analysis.
i game on a 9 year old desktop that was originally meant for proffessional studio things. but it still runs like a mid-teir desktop. it has become my main gaming rig. and due to the care it's undergone, where i've been not only gentle on it, but i have a strict routine of cleainging, small repairs, and refurbishing of small parts, and gentle handling, it's still brand new the way it runs. but the thing is i can still play high-teir games on it.
To the alien's who find this video in 10.000 years. This is our smartest caveman. We followed him because he was smarter then all of us. And yes. We still never learn what those weird two towers behind him was meant for.
@RCBones You sure? I mean 8k years ago we were just getting into pottery, not sure if we can overcome this hurdle man. (But in all seriousness I hope we will survive until then without nuking eachother into smithereens lmao, would be nice I guess)
Really interesting topic and very insightful comment about it. There are basically two fundamental solutions: updating datatypes/reformatting the way a date is calculated and stored in memory, or solving the issues of overflow on a base knowledge/data storage level. The first is almost always going to be the case, but imagine a world were we've eventually found a different mechanism for handling the "storage" or understanding of dates. I feel like we wouldn't need computers by that point.
the tax software Lacerte owned by Intuit (same people as turbo tax) has this issue with its tax calculations. It can only calculate up to 2 to the 31-1 power. I ran support for them from 2016 to 2019. Best part was the low end cost of the software was around 2k per year up to 68k a year and could not process a tax return that hit North of 2 billion. Now try to explain to a tax preparer that just spent 50k+ on their software and they have to do their biggest clients taxes by manual calculations.
@@angelgjr1999 if you are self employed or a business you have to file quarterly estimates of your taxes. So normal process is the person has an accountant prep a return based on what they think they or their business will do this year divide the tax bill by 4 and submit an estimate. Some businesses and self employed people do this estate once a year other will do it every quarter to adjust. Estimated tax payments are the same as tax withholding on a normal workers check except it is 4 times a year instead of every check, and you would get penalized if you are required to pay estimates and have not. Tax law is stupid if you really want things to be fair you implement a flat tax rate of 15% on all incomes including investments and do not allow for credits or deductions of the tax bill.
6:48 but Muta, PS1 CDs will eventually suffer from disc rot (granted we're talking at least 20 or 30 years) so unless you dump the disc contents on a hard drive as a ISO or ROM or whatever to preserve it, eventually the game will no longer work.
@@SgtSnazzerino I knew what you meant, I figure that Muta also knows as well. I was kinda being a bit facitious I think his point wasn't that a CD is better by default on its own, but because it lasts longer, and is more reliable then any digital storefront might you can use it on an unhacked console till you can hack it, and then dump it to a rom... All that makes a CD better.. For one flat fee you have options, to maintain it for life, as long as you take care of it for the time you can.
@@ProtoPropski You can do the same with digital. It's not much harder to break the store's sofware DRM than the hardware DRM of the CDs. In fact, it's often easier.
6:48 That's the fundamental issue between physical and digital games, though - digital games cannot themselves degrade (though the storage medium and hardware can...) but they can expire or be revoked without warning; physical games don't have the expiration or revocation issues, but they can degrade (e.g. disc rot) or be damaged (scratched or shattered discs, broken cartridges, cartridge connectors becoming unreadable, etc.). Which is ultimately better for preservation?
Physical. You can always copy physical games to other media...oddly enough, because of piracy!! Piracy bypasses the physical locks of a game, and it's possible to copy game roms as well (as has been done with Atari, Odessey, ColicoVision, etc. games), so you have a copy on media you own.
> physical games don't have the expiration or revocation issues I mean...the core of the issue behind the PS4 timebomb issue (which Sony thankfully fixed) was that physical games did infact have such issues. Before the update if the internal clock ever got reset and Sony's NTP server wasn't reachable for whatever reason even disc based games would refuse to run. These days physical is just digital with less convenience.
@@eldritchbeluga9277 Can you pirate PS4 games, though...? Much less PS5? Or, I don't know, Xbox One or Series games? PC and Nintendo games, sure, that's easy, along with PS1 and PS2 (and maybe PS3? Not too sure there, myself), but more recent PS games...don't think piracy is possible there.
Hey Muta. Not sure if you'll see this but I want to let you know I'm thankful for all the informative content you make. It's fun looking forward to all your videos no matter the topic. I wouldn't have a computer today if I hadn't watched your videos. Thanks bro.
I believe there was a FPGA that calculates real time differently than a typical RTC... they store the Month Day Year Seconds and milliseconds in separate memory addresses, then calls them all in one IRQ. Each of them was 16-bits? I don't remember... because I usually use systems that have EPOCH 32-bit times.
@@Greyhoundsniper its only suited for certain tasks, its expensive, typically uses more power and would still need a battery it dosent magically get power and honestly its a waste to use fpga's for such a task, cmos and RTC chips are good enough. plus now a days you can literally diy/buy a pcie atomic clock for any pc
@@Greyhoundsniper FPGAs require an external power source.... nowadays they build FPGAs as a SOC which is nice and reduces development and board real estate. However the RTC still requires a persistent power source separate from the main chip. FPGAs themselves are cheap, but damn are the dev boards pricey.... they actually replaced ASICs in the sense that you can modify it on the fly compared to requiring a silicon refactoring.
I am overwriting my comment from before to bring up the “double” integer type in C++. What it appears to be is a type of number that can handle 1024-bit integers. In other words, those numbers can go as high as ~1.7 * 10^308 seconds, which converts to about 5 * 10^300 years, or 5 with 300 zeroes after it.
Actually where i work i pointed out this problem a while ago and since, we stopped using unix timestamps for dating our db entries in favor of utc ISO dates. From what i understand they are 64bits and are human readable. So thats a plus too...
This one cracked me up when I first heard the story about PS games having their license revoked and the date being 1st January 1970. "Yep, that's a server side NTP issue and epoch time". I work with servers, I've seen it more times than I care to mention. As soon as you see "1970" in the mix, it's pretty obvious what has happened. I feel for the 1st line support folks at Sony trying to "follow the script", telling people to factory reset and so on. I guess they don't have a tonne of experience... But yeah, some server(s) somewhere in the mix have obviously shit their pants in terms of their clock settings. Hopefully it's pretty easy to resolve. I'd be kinda surprised if Sony is running kit that doesn't have NTP (network time protocol) configured.
Another example for people unaware/don't understand. If you play runescape, you'll notice a max cash stack is 2,147,483,647 coins and won't go any higher unless you examine them in your inventory. Bang, same thing.
Deep Impact was not a 'space shuttle'. The correct term is a space probe. Space Shuttle is reserved to what was officially called the Space Transportation System, that big space airplane that flew from the 1980s to the 2010s
I was 2 when Y2K was an issue, but I'll still take a seat right beside you with my Extra Salty Pop-Corn, and 32bit VirtualMachine running on the year 1999.
A good resolution for the time display bug is to quit using base 10 for years. Base 16 would lead to _future_ problems and _past_ systems wouldn't be able to cope with the year 10,000 but _then again_ how likely is it the machines we use today will be active in that timeframe? So let's observe 16-bit years in action. We are in year 7E6 right now. If we reach *base 16* 10,000, the year renders as 2710. If using hex for years, we'll encounter another issue which would be the year 65,535 problem - 0xFFFF. For the nerds in your audience, it could be argued then Cleopatra 2525 actually takes place in 9509.
There are a few cars that hit a million miles. Lots of older cars hit half that with the right care. Today though, nah. They literally would be dust by then.
Meanwhile there are people around screaming how "full digital is the future" for gaming, ready to give full control to big corporates to modify, or remove however they want the content in their store... 😶 Add on the top some random solar eruption activity and bye bye computers 🗿 👍
@@angelgjr1999 Yeah yeah and a good asteroid can set us back to Jurassic times. When we have bigger problem we can(no matter how difficult) solve like climate change, government corruption, and political instability, worrying about the sun blowing a fart is not exactly a priority.
The whole Y2K panic was not rooted in integer overflow concerns, but in the fact that many archaic systems only used TWO DIGITS to store the year. This practice dated back to the earliest days of computers, where storage was so limited that literally every character counted. And since many programs stored dates essentially as text, abbreviating from four characters to two seemed like a no-brainer. But, you say, why wouldn’t you just use those two bytes to make a 16-bit integer? Not so fast, sparky! Early systems used 6 bit bytes. Two digits it was, then!
I don’t see why they can’t just incorporate a base based system into it, similar to how you can have pointers in C, that way you’re still not using anymore memory than necessary and it can be dynamically assigned
I remember the Zune (cookies if you remember them) had a bug that bricked it because of… what was it…. When it hit year 2010. The only way to get it out of the brick mode was to take it apart, unhook the battery for a few minutes, plug everything back together, and you’re gravy. Sad about the Zune, but the software to throw music on it was kaka
Once again Runescape taught me another amazing thing in life. Just like how bronze and tin make copper, iron and coal make steel. 2147m is the maximum positive value for a 32 bit signed integer in computing.
And this is why anyone who's even remotely serious about computes should learn the programming language C. They may never write anything else but the assignments in the book, and they may never evolve to other languages. But they will understand that all modern computers are Von Neumann architectures, and they will understand how the CPU interacts with memory.
I was one of the people tasked with making embedded system y2k proof at our site (coal powerplant). In many cases we gad no choice but to "fix" the issue by dialing the clocks back to a year where the calendar happened to match up (some year in the 80's i belive) because there was no way of updating the systems which were often custom made for its purpose. Giving us about 20 more years of grace period, hoping the affected systems will get replaced before y2k rolls around again for them.
The Year 2038 problem (also known as Y2038,[1] Y2K38, or the Epochalypse[2][3]) is a time formatting bug in computer systems with representing times after 03:14:07 UTC on 19 January 2038. 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. Computer systems that use time for critical computations may encounter fatal errors if the Y2038 problem is not addressed. Some applications that use future dates have already encountered the bug. The most vulnerable systems are those which are infrequently or never updated, such as legacy and embedded systems. There is no universal solution to the problem, though many modern systems have been upgraded to measure Unix time with signed 64-bit integers which will not overflow for 292 billion years. CAUSE: Many computer systems measure time and date as Unix time, an international standard for digital timekeeping. Unix time is defined as the number of seconds elapsed since 00:00:00 UTC on 1 January 1970 (an arbitrarily chosen time), which has been dubbed the Unix epoch. Unix time has historically been encoded as a signed 32-bit integer, a data type composed of 32 binary digits (bits) which represent an integer value, with 'signed' meaning that one bit is reserved to indicate sign (+/-). Thus, a signed 32-bit integer can only represent integer values from −(231) to 231 − 1 inclusive. Consequently, if a signed 32-bit integer is used to store Unix time, the latest time that can be stored is 231 − 1 (2,147,483,647) seconds after epoch, which is 03:14:07 on Tuesday, 19 January 2038.[4] Systems that attempt to increment this value by one more second to 231 seconds after epoch (03:14:08) will suffer integer overflow, inadvertently flipping the sign bit to indicate a negative number. This changes the integer value to −(231), or 231 seconds before epoch rather than after, which systems will interpret as 20:45:52 on Friday, 13 December 1901. From here, systems will continue to count up, towards zero, and then up through the positive integers again. As many computer systems use time computations to run critical functions, the bug may introduce fatal errors.
THEY DO! Your problem was trusting the Indian who doxes his IP on stream by going to who dot is over using the cmd tool. In UNIX land, the platform Microsoft started out using for their services before NT was ever a thing, we have timespec/timeval that uses seconds + nanoseconds (
I have been working on computers before there was a PC of any sort and worked with mainframes. I have seen and worked during all the trends. Y2K was dealt with. And this 32-bit issue will be dealt with. I have no doubt. :)
"If you're using Windows XP in the year 10000, be very cautious." People on December 31st 9999, with no other piece of technology still working: *Prepares Hazmat suit*
the farthest you can scroll in years on the calendar is 2122, while 8192 is the farthest the bios reaches, but 2152 is the year seen due to never updating the date on the bottom right corner.
The same problem of integer rollover or integer overflow has occured sometimes in actual videogame gameplay. In the Playstation 1 version of Sim City, you could build giant buildings called "archologies" that could hold tens of thousands of people - if you kept crime conditions low enough for long enough. The building population was an unsigned 2-byte integer. The way to avoid the wait was to build with no nearby police station where crime conditions were already horrible, wait for the month tick where high-crime subtraction from the initial population of zero would combine with the unsigned nature of the integer to reset the population to about 65,000, upon which the listed population cap of say 30,000 for the particular type of archology would kick in as part of the month tick and downsize the population to 30,000 or whatever the listed cap was. Only then would the player surround the archology with 4 police stations, 1 police station on each side of the building. Sometimes, instead of the player cheesing a videogame, a videogame might cheese the player. In an early version of Hearts of Iron 4, which is a game meant among other things to simulate WW2 logistics, a signed integer of perhaps 19 bits was used in order to keep count of crates of infantry equipment, causing an unintended cap of well under 1 million crates of rifles and bayonets. A crate of infantry equipment was enough rifles and bayonets for 10 soldiers, and in the real version of WW2 the USA had about 10 million people in military uniform, so from a historical point of view building an inventory of 1 million crates of infantry equipment made sense. (The Soviets had a big army too.) What was really bothersome was when a player unknowingly reached the unintended cap and wondered why newly recruited divisions were training without rifles and bayonets and then checked his spare inventory, the player would find that the inventory was roughly the negative of the unintended cap. In practice, this meant that it would be a very long time before new divisions got their rifles and bayonets. The problem was fixed, and now in 2022 in what is perhaps version 11 of the Hearts of Iron 4 videogame, you can comfortably have a count of many hundreds of thousands in your infantry equipment spare inventory listing if that is what you really want to have for just in case reasons, for example just in case Japan bombs Pearl Harbor in 1941. Short version: Integer rollover or integer overflow problems can affect videogaming in ways other than being told that your videogame subsciption expired before your grandfather was born. Sometimes such computer programming problems can be used by a gamer to speed up game progress by perhaps cheesing a city simulation game in order to instantly reach a building population cap, but sometimes such problems can impose an unintended limit on a needed inventory item such as crates of rifles and bayonets in a WW2 simulation game.
That's what happened with Y2K. Most computers just left over to the original date when they were made so that's all that's going to happen just like you did during the New millennium from 1999 to 2000 and nothing really happened. Except for the dates being wrong and it wasn't easy fix if I remember correctly for most computers and companies.
i’m pretty sure this issue has been addressed years ago as well as already patched for many or most computers, so i don’t think it’s just gonna be the same as before where everyone’s pc switches to the new date and only a handful of computers screw up
11:52 Even if changing signed integers to unsigned integers were easy and free (eg you didn't have to change the assembly-language comparison operators and could do a simple binary search-and-replace), that wouldn't solve it because then it would break anything that needs to deal with dates before 1970, so for example, if you were born in 1969 (eg at Woodstock), then the system wouldn't be able to process your records. Nope, you have to change it to 64-bit signed integers, but that changes the size of the data structures which causes all kinds of cascading effects which requires re-compiling practically everything. It will be as much of a hassle as fixing the Y2K bug was, but the work is already well under way for most systems still in use, so it shouldn't be as much of a time-crunch as Y2K was. 15:38 Use SoftICE to figure out which module is deadlocked. 🤔 16:10 What? No, computers aren't abstract machines; they're finite-state machines. 🤦
Wouldn't you say virtual machines running under a 64bit machine might be an easy solution, or even THE solution to this new "Y2K". After-all, you'd theoretically have more control over the virtual environment then you would bare metal, so there's more room to make things work. Maybe not even in fixing the issue directly as 64 bit had already done, but in providing a bandaid approach.
So this will only effect consoles that display the time? I’m a Nintendo kid, and every console, Gamecube, Wii, Wii U, Switch, DS, 3DS, will all be gone? Or will it still function? I’m worried.
well honestly the hardware might be gone until then, unless you barely use it, every component has a life span, like memory, after a certain amount of read and write cycles we see corruption due to the wear and tear of the physical chip itself, that is why people support emulation and piracy is also given a thumbs up in this regard
Yeah it's so big that 128bit would be able reference every point in the known universe with micrometer precision. It could reference more that all the computer data to have ever existed on earth ( was calculated in 2017 IIRC). Needless to say it's a lot.
"When you are using Windows XP in the year 10000, be very cautious!"..... Dude, that joke just made my day. I wish someone made a movie about that age. Most movies don´t even dare to go past the year 2100. Except for The Time Machine, but that was kind of boring, because in that movie, society REGRESSES and does not progress......
Society splits, as I recall. Of course, lunar colonization was the main cause. If one looks at it through the lens of a chronicler, it looks more like a long, arduous struggle for survival between the split mortal race. I would call that *_stagnation_* rather than progress or regress, but I digress; it's a *_work of fiction._* Time travel is something to avoid.
@@angelgjr1999 man i wish those nukes fly off so the world cn finally end we have failed as a species as a whole and i think a nuclear apocalypse is the perfect punishment for us all humanity has sinned too much and fucked up everything and we all deserve to go fully extinct
As for digital copies: I've always bought physical copies, idk why people go for digital downloads. Physical copies are cheaper (especially after time and it goes down to like £10-£30). Also, you can then sell it when you've finished it and get some of your money back. You also don't have to download a huge file which not only takes a lot of time but also uses a lot of bandwidth/internet. Also, if you want to reinstall a game, with disks you just install the data on the disk. With a digital copy you have to re-download the whole game. Only drawback for physical copies is having to put them in/out the system and it takes longer to get them when you order it but next day delivery is the standard so it's not much of a drawback. Also, physical copies are just fun to collect/have. I just sold some of mine for £160 to go towards a new monitor that cost £200. Essentially got a new monitor for £40 that would have cost £200 if I didn't buy physical copies over the years.
This is always been my argument when it comes to digital vs. physical and why I prefer the latter. People were always "Ok boomering" me. And now look at that...
Correction: AD is "Anno Domini", spent my whole life calling it After Death but I learned something new.
Use code "SOG" to save money at www.gfuel.com
Check out the newest episode of the podcast: th-cam.com/video/e8A2Rn3YrOw/w-d-xo.html
Ily muta
@kyra 𖤐 bruh
Gfuel pog
WHo's ever heard of The Upchucks?
Gfuel!
finally a worthy sequel to Y2K for the younger generation!
@kyra 𖤐 radio
@kyra 𖤐 radio
@kyra 𖤐 radio
@kyra 𖤐 radio
@kyra 𖤐 radio
At my job (I am a firmware engineer) I actually had to inform one of my colleagues that the date variable he was storing the current time in seconds since 1970 on our test firmware was vulnerable to this exact 2038 bug. Our fix was replacing the data with an unsigned 64 bit data variable. Would have been funny though to think it was possible for our firmware to cease communication with the internet because it thought that it was 1901 and all certificates it had were not to be enforced until 100 years had passed.
Hahaha the computer is like boss I wanna do what your saying but the internet doesn’t exist. So, sorry bro.
@@ihateeverything9887 I want you to think about what you're saying right now.
@@megabyte3044 You have a social disorder. Regular, healthy people don't react to blatant jokes with smug aggression.
@@megabyte3044 I want you to get more human interaction so you can recognize a joke chief. It's the computer's perspective, guy's not being serious.
Had no fucking idea what your talking about but sounds smart
I remember working on the Y2K issues. It was one of my first jobs.
What people don't always know is that for some items, the fix is to assume that if the year value seen is under 70, it assumes it is after the year 2000. For anything above 70, it assumes the date is in the 20th century. I think they simply add 100 somewhere in the date calculation. This means that the system would see a 22 for the year, make it 122, then perform whatever math was needed. I don't remember the 'why' behind this, it may have been an issue with the several decades old mainframes, the COBOL language, or just having to handle so much legacy data. This does mean that if these systems are still running in 40-50 years, they may have problems again.
One old programmer said at the time, a lot of programs were designed to stop on 9/9/99, because they thought it was a fun date and the code was written in the 1970's, They never imagined their code would still be in use in 20 years.
Cool story bro
@@Lunatic5306 Useful comment bro
awesome story bro
fascinating story bro
intriguing comment brmolnar.
At least now we know to stock up on computer toilet paper in 2038... Thank you for saving the world Muta!
By 2038 your toilet paper will have DRM.
This issue will probably not be relevant for these companies, most database engines use expanded date formats. Of course this only applies to their servers and recent apps, embededd apps will most likely fail.
I farted on your cereal
NFToilet Paper
Computer toilet paper is just notepad++ change my mind.
The Y2K bug referred to at 5:45 was because prior to 2000, years were being entered as 2 digits on electronic forms, (4/4/89 for instance), and the internal programming could only accept 2 digits for the years for most programs that businesses were running on.
This meant after midnight on the last day of '99, all of the systems would roll back to '00, which would be 1900, or they would simply stop working (due to the internal calculations for ages, expiration dates, dates of renewals, and so on would start producing negative numbers which would throw out errors, with no error messages having been provided for in the programming since they lacked the foresight to do so).
So, every program that businesses used not only in the US, but around the world had to be tested to see how they would respond to the date rolling over from 12/31/99 to 1/01/00, and a very high percentage of them had to be updated, with programmers having to go in and inspect and analyze the original code and modify it from 2 digit year fields throughout the entire program to 4 digit year fields, so it would recognize the rollover from 1999 to 2000.
As an IT professional, I spent 2 years designing tests for those programs and working with developers to get the bugs out, and then retesting them to legally "certify" that they were "Y2K Ready". There were legal documents involved, and copies of the certified software so we could determine for liability purposes that only certified software was used should a problem happen in a major sector of the economy or healthcare industry should a bug be found after the New Year and cause any of the damage that it possibly could have.
It was amazing during the lead up to the year 2000 that the majority of the general public actually thought it was all a hoax... and after the New Year came and went, the majority of people could be found proudly saying "I knew it was all a hoax... so, the world didn't come to an end... nothing happened... 'cause there never was any problem to begin with"... and amazingly it's something I still run into from time to time to this day.
The one thing that not one of these individuals that was so proud of not being fooled by the supposed "hoax" ever realized, however, (until it was pointed out to them, that is) was that the entire world went from entering years as 2 digits on forms on their computers prior to the year 2000 to being **required** to enter years as 4 digit dates on their computers for everything after 1/01/2000.
It was because of that change, being required to enter years on dates as 4 digits on the vast majority of programs running on computer systems, and all of those programs that previously were coded to accept the year as 2 digits for DOB, Expiration Dates, Renewal Dates, etc. being updated to only accept 4 digits for their "year" fields that a worldwide disaster was averted and lucky for everyone, because of the efforts of an army of IT professionals who worked for years to fix that oversight by earlier programmers that we all breathed a sigh of relief after Midnight on the last day of 1999, and were able to finally say "nothing happened... thank God" due to all of that effort.
Holy shit dude
Thanks for sharing. This is key
true, i also thought it was just another "big scary thing" that was basically blown way out of proportion by the news. then again, at that time i was only 8 years old so i don't really feel too bad about not being able to understand the situation correctly lmao.
Yup. That is why we changed our personal ID number from YYMMDD[-/+]nnn to YYYYMMDD-nnnn, In Sweden.
(it used to be that + was for people who were older than 100 years old, and - those under 100 years old.)
Nothing happened in between 99 and 2000. I was using windows that time and had no issues.
Engineers have known about 32-bit limitations for as long as we've had binary, so basically forever. There are some systems that were designed for short-term usage that rely on a single, signed 32-bit epoch but not many that really matter. Old software just needs to be updated, and systems that can't be updated will need to be replaced. Everything important either already has been or will be soon. Windows already uses 64-bit time accumulators, for example.
So this isn't going to cause any serious harm to society or computer science. It's kind of alarmist hype like the Y2K scare, and you look old enough to remember Y2K. I was a kid and set my date to midnight of December 31st of 1999 and watched in suspense as nothing happened lol. Microsoft had already addressed the issue way ahead of time. Now this may do some harm to old legacy servers running outdated software, but very few of them are relevant. Any people or companies running important systems have either already dealt with this or will in the next few years.
its mostly a problem in places like airports/train stations and hospitals that are stuck using windows 98/xp and 32 bit computers... if that shit wont be updated we will have a massive downtime for transportation all around the world and there are places in the world were goverment/companies/workers do not care about switching to a newer system
@@0Blueaura ATMs, banking systems, even a lot of military systems are still using WinXP today. Although, I would like to think that crucial systems will be updated before it all comes crashing down.
I don't get how the Y2K was going to be a problem in the first place. Binary numbers can never overflow at 2000. It goes from 1024 to 2048. So how was there any problem??
@@0Blueaura What airports and train stations do you know of that are using Windows 98 or even XP? You can barely use XP at home now because it will freak out when you try to browse the web ... it can't understand modern SSL certificates, for example, and has tons of issues. Not to mention, it's incompatible with a vast number of new APIs and software that are industry standards. Networked computer systems like you see in an airport can be updated as needed, and are already using modern OS versions and hardware. They're not the issue ... updating software is completely possible, and even if the underlying hardware has to remain on a 32-bit architecture we can still fix it. A 32-bit CPU can still _use_ 64-bit integers and do 64-bit arithmetic, it just can't _natively_ index the full range of 64-bit memory addresses and 64-bit values can't be moved or manipulated in a single instruction like 64-bit CPUs do. Instead, they have to do it a bit slower with some extra steps, which only matters for heavy, high-performance computing applications and not in the context of ticking a bit per second. So we could very well continue using 32-bit hardware with upgraded software using 64-bit epochs. We just change the way software interprets the value.
Another solution is using a single byte as an additional accumulator. Instead of overflowing the epoch and going to negative numbers, it just increments the byte (we could call the variable "epoch_base") by one and sets a new epoch for the timestamp the last one ran out of bits. So if the epoch_base value is zero it's still pre-2038 time, and if the value is 1 then it's post-2038 and 3:14.08 on that day of 2038 is the new epoch base. Just one byte would allow us to do that 255 times, and it would take until 2106 (late January or February, I think) before it had to be incremented again to 00000010 (2 in decimal) and then it'd be February of 2174 when it goes to 00000011 (3) ... you'd get 68.09 more years each time you increment the epoch_base byte to set a new epoch and go back to zero seconds offset from that date. That solution would last for a total of 17,364.54 years before the byte used for the epoch_base value could overflow itself on the 256th increment, lol.
This issue is actually all about embedded and legacy systems that aren't connected to the internet and some legacy servers used to interop with old software. Some of these can't really be updated ... they could, technically, but it's easier to get rid of them and replace them usually. Some older cars, for example, have embedded systems that use this 32-bit epoch timestamp. And you'd surely see some embedded systems and legacy servers at certain factories or in other industrial facilities. Thing is, those are already aging systems and this problem is still 16 years away. Not many would even survive that long without breaking down and needing replacing prior to 2038, as they may _already_ be well over 10 years old in 2022. And how important will 25-year-old cars, for example, be to the world in 2038? How many 30-year-old embedded computer systems will still be running undisturbed that are still of any importance to the stability of society? Probably none ... only some very insignificant ones that are privately owned. Anyone doing important business won't sit idly by and watch affected systems crash in 2038 when they have 16 years to act upon it, even if it's an issue.
@@HeraldOD back then, a lot of systems and servers were storing date times as a string in DDMMYY format, not in a native binary format. And it was really major uncertainty about what would happen between software and remote servers they were relying on when they were getting date time strings like 010100 (January 1st, 2000). Turns out, some software needed to be updated but it wasn't the existential threat people feared it would be. Engineers knew about years in advance and fixed their software to account for it.
I'm a professional software engineer, and alarmists like to latch on to things like this to frighten everyone and get attention. When engineers explain a problem like this to people who don't really understand computers, they turn it into a doomsday prophecy and it's really just something we look at as an interesting engineering challenge to fix. There's nothing to worry about ... this problem doesn't exist for most modern systems, and before the 16 years are up the last embedded and legacy systems will be replaced.
Binary numbers, FYI, come in fixed sizes. 8-bit values (one byte) are the smallest type, and have a range of 256 (0 to 255). Next is a _short_ integer, a 16-bit (2-byte) value which has a range of 65,535. From there we go to 32-bit integers, with a range of 4,294,967,295 ... 64-bit values, like those native to most modern computers, go to absurdly high values (over 18-quintillion). The more times you double the width the more exponentially and absurdly large the range becomes. The numbers you named like 1024 and 2048 are powers of 2 and are very significant in computer science. You can have values with that many bits or bytes in them, but the max values when converted to decimal usually aren't anywhere near being such nice, even power of 2 numbers like that (256 being an exception). Instead we get those big decimal values like 65,535 and 4.2-billion from increasing the number of bits by powers of 2. We usually express these values in hexadecimal when doing low-level programming because binary and decimal are both unwieldy and cumbersome for notation and math and values are hard to remember. Much easier to remember 0xFF (255) or 0xFFFF (65,535) ... hex digits go from 0 to 9 and then from A to F, with 16 total digits. 0x0F is 15, and then it rolls over to 0x10 (16).
An old school computer programmer I knew bragged about fudging his mileage with analog integer overflow by spinning the odometer with a drill. He was a broke college kid at the time, just looking to save money on his summer vehicle, he wouldn't do it today even if he could.
Was your friend Roald Dahl?
@RMS Chad @@aidanallen1976 Or Danny Devito?
@@StuartWycliffe that actually worked on some analog systems back in the day. And the sawdust in the transmission really works as a band-aid. It’ll destroy the transmission tho.
That's a lot of revs on that poor drill motor!
@@369Sigma Sounds more like a narcotic than a bandaid
Fun Fact: The Nintendo GameCube, on top of using a 64-bit time type, also has its own epoch on January 1st, 2000.
IIRC, the Wii and Wii U epochs are also on January 1st, 2000.
@@MrCubFan415 same for the DSi and 3DS and I’m not sure about the original DS tho
Samsung Galaxy S2 as well
"if you're using Windows XP in the year 10000 be cautious"
Every hospital, school and my work are scared
💀💀💀💀💀
nah, by 10000,they'll upgrade all servers to Vista
The military
@@nejinaji nuclear infrastructure on floppy discs. Probably better for security in all honesty
8 bit systems ate safest :)
Computers are like that booksmart kid in college: If something isnt in the book, they freak out and lock up.
Those people are the worst. Fragile, shook little dweebs
@@riverbedfred7352 yeah! Fuck computers!
or like our brains .. its called cognitive dissonance
But strong bad, my best friend is a computer!
@@riverbedfred7352 Stuff em in lockers and call it a day
5:55 the fear of the y2k bug was that a lot of electronics use the date/year in calculations. So we feared everything would divide by zero and stop working :)
It’s pretty crazy we’re closer to the year 2040 than to the year 2000
Thx for making me feel old
Time flys.
I’m 23 and I already feel old.
Somehow, 2030 is as far away as 2014.
@@angelgjr1999 I'm 26 and felt old the moment I left high school at 19 and real life struck me like a bullet train.
I always feel that it's very important to update your system rather than letting it get to that point in the first place, so here's hoping these issues get solved ahead of time.
you're a sane human, not a money junky operating a corporation, though. 🤷🏿♂️
@@refundreplay you said that on every comment
Updates aren't always good though. Sometimes updating causes more harm than good.
@@TheSoCalledZoner1 I said that 1 time. On this comment. da fuq are you smoking?
@@Skrenja Well obviously it's not always good, but the majority of the time it's usually a good choice, or at the very least has to be done (Like those stupid Online Only games). Though I do feel more steps need to be taken to ensure that it's better more often.
4:06 Some errors. A 32-big signed integer (two's complement) can hold -2^31 to one less than 2^31. UNIX programs using a signed 32-bit integer for these dates, wouldn't wrap around to 0 (4:26) once it goes beyond 2^31-1, it would wrap to -2^31, so a time way, way in the past. Data Labs article about the year 2038 problem summarizes: "The issue with signed integers is that they don’t behave like an automobile’s odometer. When a 5-digit odometer reaches 99 999 miles, and the driver goes one extra mile, the digits “turn over” to 00000. But when a signed integer reaches its maximum value and then gets augmented, it goes back to its lowest possible negative value. Adding 1 more to the maximum value of 2,147,483,647 will cause the integer to wrap around to its minimum value of -2,147,483,647 which represents December 13, 1901, at 8:45:52 PM GMT. Any affected computer will think it traveled back in time."
A.D doesn't actually mean "After Death", it means Anno Domini, which is Latin for "in the year of our Lord".
link a source please
@@Ok-tj4ku literally every single history class and others teach you this
@@Ok-tj4ku Please tell me you're kidding...
@@Ok-tj4ku as someone who knows Latin I can confirm
@@totally.normal sure pal and the Earth is a sphere 🙄
The expiring of our games is truly a world ending event. Although we will lose genshin impact so kind of a win
checkmate, genshin fans
Not as much of a win as The upchucks!
W
Don’t you mean sexshrek? Or the prequel gayshit?
Haha genshin bad
The Y2K bug was actually similar to the Y10K one. Back in the 1970s and the 1980s, data was a rare ressource, so anything that would allow to save some bits of memory was good to take. And this is why in many systems, years were counted on double digit numbers, not the usual four digit ones. So all these old systems that still used 2 digits for years had to be updated before Y2K was reached or the system would believe it was back in 1900.
they go from 99 to 00
A buddy of mine and I had this exact conversation. We're both in IT, him in IT Solutions space, me in Dev & RnD. He and I are both in agreement that it would totally suck to be in the industry taking care of maintenance and legacy systems in the next 20 years. He and I plan to get outta the game by then and switch careers before any of that happens, occasionally popping our heads out to see what people are doing.
nigga really?
Best of luck to you and your friend. IT sucks.
Cost center, so the ceiling is usually opaque, and you always feel underappreciated by upper management. You are assigned all the blame and receive none of the accolades, especially in larger companies.
Would be fortunate to last another 20 years. (In the private sector) you're far more likely to die from stress or to be replaced by offshore contractors / "automation" before then.
Hopefully you guys accrue skills and have the ambition to form your own company. Never going to get the full value of your work while working for someone else.
The way of IT: amass as many certifications and pointless skills to pad out your resume like you're even remotely competent based on the on-paper job requirements.
Really though, IT as an industry needs to slow its roll. Business units need to take a chill pill, temper some expectations, and just calm the f*ck down. This artificial rush to be the premiere service/software/language is burning people out crazy fast.
What we need is some serious industry-wide consolidations.
Muta: "Why 2038 is the end of the world"
Me: *I sleep*
Muta: "For computers"
Me: *Real shit*
Check out 2028 end channel
It's funny you uploaded this, I've been thinking about this myself and it's super cool to hear someone talking about it
I'm a software developer and datetimes are always a pain to deal with.
In SQL server and most other databases there are two datetime integer formats. The first top's out as you advise, the second one is a massive value in the future.
One thing that also affects this is how tight the precision is, to the millisecond, microsecond, nanosecond or even picosecond, as this all takes up space in memory fitting into 32 or 64bits.
As hardware becomes faster, tighter precision will become more necessary which ends up reducing the maximum years into the future we can store.
honestly i dont know why you wouldnt just use a custom number/binary format.
like:
10 bits millis
6 bits seconds
6 bits minutes
5/6 bits hours (save space/lazy option)
9/10 bits days
and that would give you 32/34 so fit in up to 48/64 for years
so one year perfectly fits in a 32 bit if thats your limitation.
take another for the years (which isnt accessed as often and can be stored just in mem)
it's almost like computers are simply counting down the seconds until their demise, rather relatable.
As a programmer starting out of college in 1987 I remember the Y2K bug very well. The simplest way to think of it was that programmers, me included, were lazy and looked for easy ways to do date calculations. At that time we rarely ever used a four digit year, instead we would use 87 to mean 1987. The problem came in 2000 when suddenly the last two digits were 00. The maths suddenly broke, generating a negative number. What you're discussing in this video brings those old memories right back to the forefront. Thanks for the work!
This is the same reason why in WaW and BO1 Zombies become one-shot after round 163 and starts alternating between insta-kill rounds and regular rounds every other round.
And the game resets after a certain amount of time because those games are 32-bit
I heard about this Y2K bug some time ago and feel a little bit worried about system brick like what you said earlier, but glad you have talked this interesting stuff. I hope this issue get fixed or there is some workaround to fix this small but BIG issue...
By the way, love your collaborations with Dark Space GTA too.
That collab video is amazing!
I’m old enough to remember I was on call in the military for the Y2K, thinking the whole military communication network could fall down, and yet nothing happened. So I’m pretty sure this issue will be fixed before we reach 2038… if we ever do reach 2038, if you know what I mean ;)
What about older computers, like vintage machines that currently handle post 2k dates? Should their dates never be updated past 2038?
"Vintage Machines" - Good name for a futuristic movie about prototype machine learning robots from 2025 in the coming year of 10000 ;)
Why not just have the day increment instead of the year?
@RCBones yeah Y2K was a letdown because everyone spent a lot of money patching the issue, odds are 2038 will indeed be more of the same, spending a lot of money on an issue, everyone goes about as normal or perhaps even mock those who patched it in the first place. Wild world
@@therealpuzzlecube3123 Yup, I said it elsewhere in these comments: when IT does their job well, no one believes they've done anything at all.
@RCBones Well, I'm sure there were a fair share of companies that were too lazy or just not financially equipped to hire the programmers necessary to solve the Y2K programming error in any software they used... and if they were unable to do that and it caused enough problems it could have led to their company closing (assuming they relied heavily on such programs). But I can't name any off the top of my head.
This issue I'm sure can and will be easily fixed with our technology in the next 16 years.. I'm sure a programmer can up the integer counts totality or extend it another 100 years
The issue is more likely that systems that works offline needs to be updated manually and that the owner of these systems may not know about the issue or capable of doing the update themself. Some older systems like Windows XP is not longer maintained by Microsoft, those kind of systems needs to be rebuilt to handle time different by someone with knowledge or updated to a later version of Windows / switched to different OS that is still being maintained. Updating an older system that contains databases and such comes with a risk of loosing data during the time of update or due to corruption of data when the update is done.
@@Muurcas Don't you think people that use Windows XP are all died out by the year 2038?
It's usually not that simple. The farther back you go the more important individual bits are.
@@Forcoy linux machines usually can pose as good alternatives as you go back further and further
Those kids 100 years into the future are gonna piss themselves
Wow Mutahar, I didn't know eunuchs were so important for computing! Glad we have you around.
I've had a similar issue with my grid-based computational fluid dynamics software lately.
I implemented several methods to reduce memory demand, so that larger grid resolution is possible in limited GPU memory. But resolution got so large that the 32-bit unsigned integer index for the grid cells started overflowing in some places.
Without going full 64-bit integer (GPUs can't handle 64-bit int on CUDA cores, so there would be slowdown), the limit is now at the full extent that 32-bt allows, 2³² grid points. This is equivalent to 225GB VRAM. Few years left until hardware will surpass that limit, currently the largest GPU has 128GB.
i understood this completely!
Whut?
A clock glitch might not break a physical PS1 game, but disc rot will. If it has DRM, you don't own it and you can't preserve it.
Thats why Rom's and ISO's + Emulation is the way to go. Once you have it digitally, with several backups, they're pretty much eternal.
DRM can be patched out and pirates take the DRM out. So you can preserve DRM games even though you "don't own it". The pirates don't, yet they do it anyway.
Depending on how a PSX disc is stored, you could probably be assured it's rot-free for another two decades from now; give or take. Making a backup disc once you suspect rot may be coming soon isn't illegal either: you are fully allowed to rip the ROM off the disc for personal preservation purposes.
Now, if you're playing the games on a PC, you can just play the backup disc while the original rots; no problem (the illegal part is the BIOS the emulator requires). If you want to be completely legal, you can disc-swap the backup with the original (the original disc has DRM that the backup won't have because Sony used proprietary-coded CDs to print games) or mod-chip the PSX; both of those are legal, but the latter will void the warranty on a 30+ year old piece of hardware.
Finally, as disc-rot becomes more prevalent in the future, we can bet our bottom dollar there will be products that allow us to successfully duplicate the games, DRM and all. It may be expensive, as any super-niche product tends to be, but a market will get catered to. Perhaps Sony will let the PSX BIOS enter the public domain or license it out to a third-party, in which case that PSX emulator becomes completely legal to use.
Or maybe Sony will go out of business and take their library down with them, which would mean there won't be anyone to prosecute you for using their BIOS. It would still technically be illegal to emulate the library at that point, but ethically you'd be in the clear because you literally could not pay a company that no longer exists for the "legit" experience.
tl;dr - You own it, and you can preserve it. You just have to be creative or willing to spend money; or both.
@@TheKrossRoads now that there's products like the psio or the xstation, it's a lot easier to play games with almost 100% compatibility on a real console. it's not like psx lasers are eternal, sadly, we're going to have to move on to modding sometime.
"If it has DRM, you don't own it and you can't preserve it"
*Laughs in DRM crack*
this is super interesting. i remember seeing that tom scott video about the unix epoch iphone brick and my mind was blown
Blizzard created their own packed time algorithm for WoW's calendar where various measurements of time are all stored in a single 32-bit integer. Only 5 bytes are used for the year and the starting year is 2000, which means 2031 is the end for it.
I wonder if this is still the case. WC3 had similar bug when it was released. It catched my eye recently - Patch 1.03 - Fixed a crash that could occur when the system date was set to > 2038. Maybe they did some similar bugfix to wow too?
Cisco had some software that :-
1. Counted "units of time" exactly like UNIX time. Add 1 every time the "unit of time" has passed.
2. Used "4 milliseconds" as a unit of time instead of the second.
3. Stored the value in a 32bit signed int.
This gave it just under 99.5 days before it overflowed. Once it overflowed (to -2^32), all the hardware packet forwarding features still worked, but nothing that talked to the main system CPU would work. The system wouldn't answer pings, all routing protocol sessions to it failed, you couldn't SSH into it or even use the serial console etc ...
We had several of these in a lab, and something clearly was still going on. Because after another ~99.5 days when the timer got back from -2^32 to 0, the system just popped back into life again. In a slightly goofy state, but you could ping it again, you could login to again etc ...
Cisco's solution though ... reboot these devices every 95 days ...
bruh
respect to the fact they just said "screw it, we'll just reset it" but damn hope no other companies decide to take that route. would suck to see every few years another update you'd have to install because of bad computing counting.
Windows used to have a similar uptime issue, but most people didn't remain up without a reboot/crash long enough to run into it.
lmao, literally "try turning it off and on again"
Unrelated to the 2038 problem, the company I work for uses a variety of different Unix units to store time from dates to hours to minutes to seconds to microseconds. It is really up to the engineering team's perceived need for time measurements.
I always loath having to worry about the correct conversion function to include everytime I need to do time series data analysis.
I'm willing to bet the MSM is going to try to pull another Y2K scare over this
U say u have no name, that means ur name is Steve.
what's msm
@@cayben8865 mainstream media
drumpf
@@cayben8865 mechanically separated meat
we dont even gotta worry our worlds gonna kick the bucket before the computers do by the way its looking
humans survived tge ice age when we were barely able to speak lol well be fine . the orld as we know it wont
Nah lol we will live until then and then some
Are you confident in that statement when those damn dinosaurs survived a gigantic meteor blew the fuck out of Central America?
i game on a 9 year old desktop that was originally meant for proffessional studio things. but it still runs like a mid-teir desktop. it has become my main gaming rig. and due to the care it's undergone, where i've been not only gentle on it, but i have a strict routine of cleainging, small repairs, and refurbishing of small parts, and gentle handling, it's still brand new the way it runs. but the thing is i can still play high-teir games on it.
To the alien's who find this video in 10.000 years. This is our smartest caveman. We followed him because he was smarter then all of us. And yes. We still never learn what those weird two towers behind him was meant for.
Evolution
What if they dont know english? Or any other language in our modern time?
"Two towers"
@@Greyhoundsniper 🎲
@@MONO-_-187 Reminder that contrary to popular belief, evolution is survival of the "good enough" not survival of the "fittest"
Damn, really worried about that 5 digit year issue, hope we figure it out quick.
Just remove clocks from the equation. Use timestamps and authentication files
Programmers will just reset the system clocks to 1970 :)
@RCBones You sure? I mean 8k years ago we were just getting into pottery, not sure if we can overcome this hurdle man. (But in all seriousness I hope we will survive until then without nuking eachother into smithereens lmao, would be nice I guess)
Lets just stop tracking time at all. Easy as.
What day is it? Who tf cares!
@Anonymous Honestly that song has real fallout energy. With that 40s-50s style
Really interesting topic and very insightful comment about it. There are basically two fundamental solutions: updating datatypes/reformatting the way a date is calculated and stored in memory, or solving the issues of overflow on a base knowledge/data storage level. The first is almost always going to be the case, but imagine a world were we've eventually found a different mechanism for handling the "storage" or understanding of dates. I feel like we wouldn't need computers by that point.
the tax software Lacerte owned by Intuit (same people as turbo tax) has this issue with its tax calculations. It can only calculate up to 2 to the 31-1 power. I ran support for them from 2016 to 2019. Best part was the low end cost of the software was around 2k per year up to 68k a year and could not process a tax return that hit North of 2 billion. Now try to explain to a tax preparer that just spent 50k+ on their software and they have to do their biggest clients taxes by manual calculations.
Don’t rich people do their tax quarterly? So in theory a billionaire would file for 250 million every 3 months.
@@angelgjr1999 uhh.....
@@angelgjr1999 I dunno, call up Bezos or something.
@@angelgjr1999 if you are self employed or a business you have to file quarterly estimates of your taxes. So normal process is the person has an accountant prep a return based on what they think they or their business will do this year divide the tax bill by 4 and submit an estimate. Some businesses and self employed people do this estate once a year other will do it every quarter to adjust. Estimated tax payments are the same as tax withholding on a normal workers check except it is 4 times a year instead of every check, and you would get penalized if you are required to pay estimates and have not. Tax law is stupid if you really want things to be fair you implement a flat tax rate of 15% on all incomes including investments and do not allow for credits or deductions of the tax bill.
@@jackestes44 I agree a flat tax rate would be the best. It’s unfair how there’s people that pay zero tax, while others pay 30-40%.
6:48 but Muta, PS1 CDs will eventually suffer from disc rot (granted we're talking at least 20 or 30 years) so unless you dump the disc contents on a hard drive as a ISO or ROM or whatever to preserve it, eventually the game will no longer work.
There you go, crisis averted, emulate.
@@ProtoPropski I know that I'm just saying muta shouldn't put all his faith on the OG PS1 CD
@@SgtSnazzerino
I knew what you meant, I figure that Muta also knows as well. I was kinda being a bit facitious
I think his point wasn't that a CD is better by default on its own, but because it lasts longer, and is more reliable then any digital storefront might you can use it on an unhacked console till you can hack it, and then dump it to a rom... All that makes a CD better..
For one flat fee you have options, to maintain it for life, as long as you take care of it for the time you can.
@@ProtoPropski You can do the same with digital. It's not much harder to break the store's sofware DRM than the hardware DRM of the CDs. In fact, it's often easier.
Muta your on a Crazy streak.Thanks for the daily Uploads and getting to learn new things everytime about Computer/VB etc
Keep it up❤️❤️❤️
Love ya Muta, final volume of Berserk coming out in November I believe. I weeped over the news in happiness.
R.I.P Kentaro Miura
6:48 That's the fundamental issue between physical and digital games, though - digital games cannot themselves degrade (though the storage medium and hardware can...) but they can expire or be revoked without warning; physical games don't have the expiration or revocation issues, but they can degrade (e.g. disc rot) or be damaged (scratched or shattered discs, broken cartridges, cartridge connectors becoming unreadable, etc.).
Which is ultimately better for preservation?
Physical. You can always copy physical games to other media...oddly enough, because of piracy!! Piracy bypasses the physical locks of a game, and it's possible to copy game roms as well (as has been done with Atari, Odessey, ColicoVision, etc. games), so you have a copy on media you own.
Clearly doing both is the best option... as long as you don't consult your wallet
> physical games don't have the expiration or revocation issues
I mean...the core of the issue behind the PS4 timebomb issue (which Sony thankfully fixed) was that physical games did infact have such issues. Before the update if the internal clock ever got reset and Sony's NTP server wasn't reachable for whatever reason even disc based games would refuse to run. These days physical is just digital with less convenience.
Or, hear me out, you can do it like the good old days and pirate games.
*But don't pirate indie devs, theyre trying their best
@@eldritchbeluga9277 Can you pirate PS4 games, though...? Much less PS5? Or, I don't know, Xbox One or Series games?
PC and Nintendo games, sure, that's easy, along with PS1 and PS2 (and maybe PS3? Not too sure there, myself), but more recent PS games...don't think piracy is possible there.
gotta love when muta drops these vids so informal.
Computers have been around that long, which is incredible.
The human brain is a very powerful computer, Dare I say an ancient computer. (VERY LONG). You are incredible.
They have been around at least from 1800s
@@aodigital9421 There's too many daemons, bloat, legacy features, and spaghetti code left in there though :(
@@aodigital9421 Only a few of them are good.
@@oz_jones probably taking about CMOS computers...not vacuum tube computers
I love this kind of content, keep it up Muta!
@YeaMan ok buddy
@YeaMan ratio
@@mbynot I support the cause 👍
agreed
Hey Muta.
Not sure if you'll see this but I want to let you know I'm thankful for all the informative content you make. It's fun looking forward to all your videos no matter the topic. I wouldn't have a computer today if I hadn't watched your videos. Thanks bro.
I believe there was a FPGA that calculates real time differently than a typical RTC...
they store the Month Day Year Seconds and milliseconds in separate memory addresses, then calls them all in one IRQ.
Each of them was 16-bits?
I don't remember... because I usually use systems that have EPOCH 32-bit times.
I'm suprised a FPGA hasn't replaced coin batteries in storing real time
@@Greyhoundsniper its only suited for certain tasks, its expensive, typically uses more power and would still need a battery it dosent magically get power and honestly its a waste to use fpga's for such a task, cmos and RTC chips are good enough. plus now a days you can literally diy/buy a pcie atomic clock for any pc
@@Greyhoundsniper FPGAs require an external power source.... nowadays they build FPGAs as a SOC which is nice and reduces development and board real estate. However the RTC still requires a persistent power source separate from the main chip.
FPGAs themselves are cheap, but damn are the dev boards pricey.... they actually replaced ASICs in the sense that you can modify it on the fly compared to requiring a silicon refactoring.
But since FPGAs have slower clock speeds than regular CPUs and GPUs, won't that affect how quickly the IRQs are handled?
@@amurnotgood3112 you cant compare different architectures like that...
FPGAs are application specific compared to CPUs/GPUs which uses Task Handlers
Hopefully this can make a sequel to my favorite family guy episode come to fruition.
Found you.
@@gaymansupreme ayo
@YeaMan you ever get the feeling that you're posts make you look like a 🤡
I am overwriting my comment from before to bring up the “double” integer type in C++. What it appears to be is a type of number that can handle 1024-bit integers. In other words, those numbers can go as high as ~1.7 * 10^308 seconds, which converts to about 5 * 10^300 years, or 5 with 300 zeroes after it.
Actually where i work i pointed out this problem a while ago and since, we stopped using unix timestamps for dating our db entries in favor of utc ISO dates. From what i understand they are 64bits and are human readable. So thats a plus too...
This one cracked me up when I first heard the story about PS games having their license revoked and the date being 1st January 1970.
"Yep, that's a server side NTP issue and epoch time".
I work with servers, I've seen it more times than I care to mention. As soon as you see "1970" in the mix, it's pretty obvious what has happened.
I feel for the 1st line support folks at Sony trying to "follow the script", telling people to factory reset and so on. I guess they don't have a tonne of experience... But yeah, some server(s) somewhere in the mix have obviously shit their pants in terms of their clock settings.
Hopefully it's pretty easy to resolve. I'd be kinda surprised if Sony is running kit that doesn't have NTP (network time protocol) configured.
Another example for people unaware/don't understand.
If you play runescape, you'll notice a max cash stack is 2,147,483,647 coins and won't go any higher unless you examine them in your inventory.
Bang, same thing.
Deep Impact was not a 'space shuttle'. The correct term is a space probe. Space Shuttle is reserved to what was officially called the Space Transportation System, that big space airplane that flew from the 1980s to the 2010s
Someone already said it, but I wanna say it too: I'm excited to watch the freakout, as someone who went thru Y2K and found that funny too
I was 2 when Y2K was an issue, but I'll still take a seat right beside you with my Extra Salty Pop-Corn, and 32bit VirtualMachine running on the year 1999.
A good resolution for the time display bug is to quit using base 10 for years. Base 16 would lead to _future_ problems and _past_ systems wouldn't be able to cope with the year 10,000 but _then again_ how likely is it the machines we use today will be active in that timeframe?
So let's observe 16-bit years in action. We are in year 7E6 right now. If we reach *base 16* 10,000, the year renders as 2710. If using hex for years, we'll encounter another issue which would be the year 65,535 problem - 0xFFFF.
For the nerds in your audience, it could be argued then Cleopatra 2525 actually takes place in 9509.
9:23 I heard tales of a man who once drove his mighty Dodge for 1 million miles; this man also scored four touchdowns in a single game.
Million mile cars are starting to become more common. Cars are built pretty well nowadays.
There are a few cars that hit a million miles. Lots of older cars hit half that with the right care. Today though, nah. They literally would be dust by then.
That was the first thing I thought of. What a legend he was.
Meanwhile there are people around screaming how "full digital is the future" for gaming, ready to give full control to big corporates to modify, or remove however they want the content in their store... 😶 Add on the top some random solar eruption activity and bye bye computers 🗿 👍
turn off tge grid when solar flare hits and youre fine... and its called blockchain dude .. your worries have already been fixed a decade ago lol
Yeah nobody seems to be talking about the increased solar activity in recent years. A solar flare can literally set us back to the dark ages…
@@angelgjr1999 Yeah yeah and a good asteroid can set us back to Jurassic times. When we have bigger problem we can(no matter how difficult) solve like climate change, government corruption, and political instability, worrying about the sun blowing a fart is not exactly a priority.
That’s what already happens with movies, music and tv shows with all these streaming services
@@drunkenthoughts6072 Kinda sad we aren’t solving any of the problems you mentioned.
The whole Y2K panic was not rooted in integer overflow concerns, but in the fact that many archaic systems only used TWO DIGITS to store the year. This practice dated back to the earliest days of computers, where storage was so limited that literally every character counted. And since many programs stored dates essentially as text, abbreviating from four characters to two seemed like a no-brainer. But, you say, why wouldn’t you just use those two bytes to make a 16-bit integer? Not so fast, sparky! Early systems used 6 bit bytes. Two digits it was, then!
I don’t see why they can’t just incorporate a base based system into it, similar to how you can have pointers in C, that way you’re still not using anymore memory than necessary and it can be dynamically assigned
Based base vs virgin baseless system
The Problem is legacy, you have to patch "old legacy Code to a new date system"
I remember the Zune (cookies if you remember them) had a bug that bricked it because of… what was it…. When it hit year 2010.
The only way to get it out of the brick mode was to take it apart, unhook the battery for a few minutes, plug everything back together, and you’re gravy.
Sad about the Zune, but the software to throw music on it was kaka
Wow zune itself predicted it would die before 2010? I remember the iPod/MP3/limewire era.
Once again Runescape taught me another amazing thing in life. Just like how bronze and tin make copper, iron and coal make steel. 2147m is the maximum positive value for a 32 bit signed integer in computing.
nah -1 is
AD does not stand for After Death, Christ wasn’t alive for a year. It stands for Anno Domini, which translates to “the year of our lord”
Was about to comment the same thing
Huh, learn new things everyday.
And this is why anyone who's even remotely serious about computes should learn the programming language C. They may never write anything else but the assignments in the book, and they may never evolve to other languages. But they will understand that all modern computers are Von Neumann architectures, and they will understand how the CPU interacts with memory.
Are we just ignoring that modified Harvard is a thing?
I was one of the people tasked with making embedded system y2k proof at our site (coal powerplant).
In many cases we gad no choice but to "fix" the issue by dialing the clocks back to a year where the calendar happened to match up (some year in the 80's i belive) because there was no way of updating the systems which were often custom made for its purpose.
Giving us about 20 more years of grace period, hoping the affected systems will get replaced before y2k rolls around again for them.
Muta’s computer is going to end in 3005
Hold up?
We'd be dead. 💀
Bruh the first half of the title got me not gonna lie. good job muta
Thank you for taking the time to teach stuff like this. I REALLY REALLY enjoy learning new things and you make it so easy to understand!!
When muta makes a video about it, then it's something to be afraid of
Sheep moment
@@LISBONKULT dude ong istg so many people are like following this man with no second thought
So... Just upgrade all your machines to 64 bit Windows/Linux. Super easy
🤓
🤓
😎
All of my PCs are 64 bit lol
4Head Just
The Year 2038 problem (also known as Y2038,[1] Y2K38, or the Epochalypse[2][3]) is a time formatting bug in computer systems with representing times after 03:14:07 UTC on 19 January 2038.
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.
Computer systems that use time for critical computations may encounter fatal errors if the Y2038 problem is not addressed. Some applications that use future dates have already encountered the bug. The most vulnerable systems are those which are infrequently or never updated, such as legacy and embedded systems. There is no universal solution to the problem, though many modern systems have been upgraded to measure Unix time with signed 64-bit integers which will not overflow for 292 billion years.
CAUSE:
Many computer systems measure time and date as Unix time, an international standard for digital timekeeping. Unix time is defined as the number of seconds elapsed since 00:00:00 UTC on 1 January 1970 (an arbitrarily chosen time), which has been dubbed the Unix epoch.
Unix time has historically been encoded as a signed 32-bit integer, a data type composed of 32 binary digits (bits) which represent an integer value, with 'signed' meaning that one bit is reserved to indicate sign (+/-). Thus, a signed 32-bit integer can only represent integer values from −(231) to 231 − 1 inclusive. Consequently, if a signed 32-bit integer is used to store Unix time, the latest time that can be stored is 231 − 1 (2,147,483,647) seconds after epoch, which is 03:14:07 on Tuesday, 19 January 2038.[4] Systems that attempt to increment this value by one more second to 231 seconds after epoch (03:14:08) will suffer integer overflow, inadvertently flipping the sign bit to indicate a negative number. This changes the integer value to −(231), or 231 seconds before epoch rather than after, which systems will interpret as 20:45:52 on Friday, 13 December 1901. From here, systems will continue to count up, towards zero, and then up through the positive integers again. As many computer systems use time computations to run critical functions, the bug may introduce fatal errors.
I guess we have to be using Flintstones computers after 2038.
He actually said 298 Billion years from now.
They can just implement another variable to multiply
Like time after 2038 is maxEpoch * timeEpochPassed + currentEpoch
Or....use overflow bits, or flag bits?
Who said your limit to just one address?
THEY DO! Your problem was trusting the Indian who doxes his IP on stream by going to who dot is over using the cmd tool. In UNIX land, the platform Microsoft started out using for their services before NT was ever a thing, we have timespec/timeval that uses seconds + nanoseconds (
@@reecesx why does muta being indian matter here?
@@aether5533 because the funny /g/ p word is likely censored
Correct
I have been working on computers before there was a PC of any sort and worked with mainframes. I have seen and worked during all the trends. Y2K was dealt with. And this 32-bit issue will be dealt with. I have no doubt. :)
"If you're using Windows XP in the year 10000, be very cautious."
People on December 31st 9999, with no other piece of technology still working: *Prepares Hazmat suit*
the farthest you can scroll in years on the calendar is 2122, while 8192 is the farthest the bios reaches, but 2152 is the year seen due to never updating the date on the bottom right corner.
The same problem of integer rollover or integer overflow has occured sometimes in actual videogame gameplay.
In the Playstation 1 version of Sim City, you could build giant buildings called "archologies" that could hold tens of thousands of people - if you kept crime conditions low enough for long enough. The building population was an unsigned 2-byte integer. The way to avoid the wait was to build with no nearby police station where crime conditions were already horrible, wait for the month tick where high-crime subtraction from the initial population of zero would combine with the unsigned nature of the integer to reset the population to about 65,000, upon which the listed population cap of say 30,000 for the particular type of archology would kick in as part of the month tick and downsize the population to 30,000 or whatever the listed cap was. Only then would the player surround the archology with 4 police stations, 1 police station on each side of the building.
Sometimes, instead of the player cheesing a videogame, a videogame might cheese the player. In an early version of Hearts of Iron 4, which is a game meant among other things to simulate WW2 logistics, a signed integer of perhaps 19 bits was used in order to keep count of crates of infantry equipment, causing an unintended cap of well under 1 million crates of rifles and bayonets. A crate of infantry equipment was enough rifles and bayonets for 10 soldiers, and in the real version of WW2 the USA had about 10 million people in military uniform, so from a historical point of view building an inventory of 1 million crates of infantry equipment made sense. (The Soviets had a big army too.) What was really bothersome was when a player unknowingly reached the unintended cap and wondered why newly recruited divisions were training without rifles and bayonets and then checked his spare inventory, the player would find that the inventory was roughly the negative of the unintended cap. In practice, this meant that it would be a very long time before new divisions got their rifles and bayonets. The problem was fixed, and now in 2022 in what is perhaps version 11 of the Hearts of Iron 4 videogame, you can comfortably have a count of many hundreds of thousands in your infantry equipment spare inventory listing if that is what you really want to have for just in case reasons, for example just in case Japan bombs Pearl Harbor in 1941.
Short version: Integer rollover or integer overflow problems can affect videogaming in ways other than being told that your videogame subsciption expired before your grandfather was born. Sometimes such computer programming problems can be used by a gamer to speed up game progress by perhaps cheesing a city simulation game in order to instantly reach a building population cap, but sometimes such problems can impose an unintended limit on a needed inventory item such as crates of rifles and bayonets in a WW2 simulation game.
We are all truly blessed to have a guy as rad as Muta showing us the ropes in the wacky world of tech!!!!
That's what happened with Y2K. Most computers just left over to the original date when they were made so that's all that's going to happen just like you did during the New millennium from 1999 to 2000 and nothing really happened. Except for the dates being wrong and it wasn't easy fix if I remember correctly for most computers and companies.
Having a uncle like muta would be freaking awesome!!
Love ur vids thanks so much for helping me through dark times. I doubt you will see this but thanks so much
You should use a virtual machine for windows 10 and change the date to year 262 billion and see what happens then
i’m pretty sure this issue has been addressed years ago as well as already patched for many or most computers, so i don’t think it’s just gonna be the same as before where everyone’s pc switches to the new date and only a handful of computers screw up
Such amazing content, so much information, thank you muta.
You know I’ve been quite in time for your videos lately and idk why I wasn’t on time before usually
there's a fuckload of calendars. Just go to the wikipedia page for any year, it'll list it in basically every type of calendar - pretty cool.
Oh god how is Muta Gonna Heighten my anxiety today lol
11:52 Even if changing signed integers to unsigned integers were easy and free (eg you didn't have to change the assembly-language comparison operators and could do a simple binary search-and-replace), that wouldn't solve it because then it would break anything that needs to deal with dates before 1970, so for example, if you were born in 1969 (eg at Woodstock), then the system wouldn't be able to process your records. Nope, you have to change it to 64-bit signed integers, but that changes the size of the data structures which causes all kinds of cascading effects which requires re-compiling practically everything. It will be as much of a hassle as fixing the Y2K bug was, but the work is already well under way for most systems still in use, so it shouldn't be as much of a time-crunch as Y2K was.
15:38 Use SoftICE to figure out which module is deadlocked. 🤔
16:10 What? No, computers aren't abstract machines; they're finite-state machines. 🤦
Wouldn't you say virtual machines running under a 64bit machine might be an easy solution, or even THE solution to this new "Y2K".
After-all, you'd theoretically have more control over the virtual environment then you would bare metal, so there's more room to make things work.
Maybe not even in fixing the issue directly as 64 bit had already done, but in providing a bandaid approach.
"Here's actually a visual representation of what you're supposed to see."
*tremfya ad begins playing.*
So this will only effect consoles that display the time? I’m a Nintendo kid, and every console, Gamecube, Wii, Wii U, Switch, DS, 3DS, will all be gone? Or will it still function? I’m worried.
I was thinking about 3ds too but the system date and time is set by the user and the date goes to 2050 so it should be fine until then
If my wii u and switch spontaniously die in 2038 I'm gonna be fucking PISSED
Wait but GameCube doesn't use huge internet usage unless it's PS:O
well honestly the hardware might be gone until then, unless you barely use it, every component has a life span, like memory, after a certain amount of read and write cycles we see corruption due to the wear and tear of the physical chip itself, that is why people support emulation and piracy is also given a thumbs up in this regard
Switch should be fine
Wonder when we’re going to have 128-bit CPUs and how long THAT will last
Legit no one talk how massive that jump.
Yeah it's so big that 128bit would be able reference every point in the known universe with micrometer precision. It could reference more that all the computer data to have ever existed on earth ( was calculated in 2017 IIRC).
Needless to say it's a lot.
Never have I laughed harder than after hearing Muta calling AD "After Death". Thank you Muta.
"When you are using Windows XP in the year 10000, be very cautious!".....
Dude, that joke just made my day. I wish someone made a movie about that age. Most movies don´t even dare to go past the year 2100. Except for The Time Machine, but that was kind of boring, because in that movie, society REGRESSES and does not progress......
Primordial soup all over again.
Society splits, as I recall. Of course, lunar colonization was the main cause. If one looks at it through the lens of a chronicler, it looks more like a long, arduous struggle for survival between the split mortal race. I would call that *_stagnation_* rather than progress or regress, but I digress; it's a *_work of fiction._* Time travel is something to avoid.
I never thought I’d live through 2 Y2K events in my life tbh, at least now I’m sentient and can experience everyone freaking out lmao
Also if this makes me unable to play sims 3 in the distant future I’m gonna go bezerk
You’re assuming we make it to 2038. Lol
At this rate who knows, I wonder how the old nuclear systems will react…
@@angelgjr1999 nah we will live until then any beyond
@@angelgjr1999 lol true, I’m doubting we make it another decade without wiping each other out. I’m just gonna vibe until then : )
@@angelgjr1999 man i wish those nukes fly off so the world cn finally end
we have failed as a species as a whole and i think a nuclear apocalypse is the perfect punishment for us all
humanity has sinned too much and fucked up everything and we all deserve to go fully extinct
As for digital copies:
I've always bought physical copies, idk why people go for digital downloads. Physical copies are cheaper (especially after time and it goes down to like £10-£30). Also, you can then sell it when you've finished it and get some of your money back. You also don't have to download a huge file which not only takes a lot of time but also uses a lot of bandwidth/internet. Also, if you want to reinstall a game, with disks you just install the data on the disk. With a digital copy you have to re-download the whole game.
Only drawback for physical copies is having to put them in/out the system and it takes longer to get them when you order it but next day delivery is the standard so it's not much of a drawback.
Also, physical copies are just fun to collect/have. I just sold some of mine for £160 to go towards a new monitor that cost £200. Essentially got a new monitor for £40 that would have cost £200 if I didn't buy physical copies over the years.
This is always been my argument when it comes to digital vs. physical and why I prefer the latter. People were always "Ok boomering" me. And now look at that...