Were there concrete examples of critical software that actually would’ve failed? At the time I remember there was one consultant that was on the news constantly saying everything from elevators to microwaves would fail on Y2K. Of course this was creating a lot of business for his company.
When you think about it storing a date with 6 bytes would take more space than using Unix time which would give both time and date in four bytes. Y2K38 is the real problem. Y2K was a problem with software written by poor devs that were trying to save disk space by actually using more disk space than needed.
And sure a lot of of software needed to be tested to be sure someone didn’t do something stupid. But a lot of it was indeed an exaggeration. You have to reset the time on your microwave after a power outage but not the date, common sense tells you your microwave doesn’t care about the year. And when a reporter actually followed up with the elevator companies, it was the same deal. Most software simply doesn’t just fail when it’s run in an unexpected year.
If someone wrote a time critical safety mechanism for a nuclear reactor that involved parsing a janky homebrew time format from a string then there’s some serious problems in that software way beyond Y2K.
The instances of the Y2K bug I saw in the wild, the software still worked, it just displayed the date wrong.
Y2K38 is the real scary problem because people that don’t understand binary numbers don’t understand it at all. And even a lot of people in the technology field think it’s not a problem because “computers are 64 bit now.” Don’t matter how many bits the processor has, it’s only the size that’s compiled and stored that counts. And unlike some janky parsed string format, unix time is a format I could see systems at power plants actually using.
When you think about it storing a date with 6 bytes would take more space than using Unix time which would give both time and date in four bytes. Y2K38 is the real problem. Y2K was a problem with software written by poor devs that were trying to save disk space by actually using more disk space than needed.
This comes to mind:
You don’t store dates as Unix time. Unix timestamps indicate a specific point in time. Dates are not a specific point in time.
You also don’t store dates in a string that you’ll have to parse later. I’ve had to deal with MM-DD-YYYY vs. DD-MM-YYYY problems more times than I can count.
And you understand that you could have a date in unix time and leave the time to be midnight, right? You’d end up with an integer that you could sort without having to parse every goddamn string first.
And for God’s sake if you insist on using strings for dates at the very least go with something like YYYY-MM-DD. Someone else may someday have to deal with your shit code, at the very least make the strings sortable FFS.
You’re saying “imagine” a lot there.
Were there concrete examples of critical software that actually would’ve failed? At the time I remember there was one consultant that was on the news constantly saying everything from elevators to microwaves would fail on Y2K. Of course this was creating a lot of business for his company.
When you think about it storing a date with 6 bytes would take more space than using Unix time which would give both time and date in four bytes. Y2K38 is the real problem. Y2K was a problem with software written by poor devs that were trying to save disk space by actually using more disk space than needed.
And sure a lot of of software needed to be tested to be sure someone didn’t do something stupid. But a lot of it was indeed an exaggeration. You have to reset the time on your microwave after a power outage but not the date, common sense tells you your microwave doesn’t care about the year. And when a reporter actually followed up with the elevator companies, it was the same deal. Most software simply doesn’t just fail when it’s run in an unexpected year.
If someone wrote a time critical safety mechanism for a nuclear reactor that involved parsing a janky homebrew time format from a string then there’s some serious problems in that software way beyond Y2K.
The instances of the Y2K bug I saw in the wild, the software still worked, it just displayed the date wrong.
Y2K38 is the real scary problem because people that don’t understand binary numbers don’t understand it at all. And even a lot of people in the technology field think it’s not a problem because “computers are 64 bit now.” Don’t matter how many bits the processor has, it’s only the size that’s compiled and stored that counts. And unlike some janky parsed string format, unix time is a format I could see systems at power plants actually using.
Some of the software at my employer at the time, would have failed. In particular, I fixed some currency trading software
This comes to mind:
You don’t store dates as Unix time. Unix timestamps indicate a specific point in time. Dates are not a specific point in time.
You also don’t store dates in a string that you’ll have to parse later. I’ve had to deal with MM-DD-YYYY vs. DD-MM-YYYY problems more times than I can count.
And you understand that you could have a date in unix time and leave the time to be midnight, right? You’d end up with an integer that you could sort without having to parse every goddamn string first.
And for God’s sake if you insist on using strings for dates at the very least go with something like YYYY-MM-DD. Someone else may someday have to deal with your shit code, at the very least make the strings sortable FFS.