(Y2K, i.e. the “year 2000 problem”, affected two digit date formats. Nothing bad happened, but consensus nowadays is that that wasn’t because the issue was overblown, it’s because the issue was recognized and seriously addressed. Lots of already retired or soon retiring programmers came back to fix stuff in ancient software and made bank. In 2038, another very common date format will break. I’d say it’s much more common than 2 digit dates, but 2 digit dates may have been more common in 1985. It’s going to require a massive remediation effort and I hope AI-assisted static analysis will be viable enough to help us by then.)
My dad is a tech in the telecommunications industry. We basically didn’t see him for all of 1999. The fact that nothing happened is because of people working their assess off.
I get the joke, but for those seriously wondering:
The epoch is Jan 1, 1970. Time uses a signed integer, so you can express up to 2^31 seconds with 32 bits or 2^63 with 64 bits.
A normal year has exactly 31536000 seconds (even if it is a leap second year, as those are ignored for Unix time). 97 out of 400 years are leap years, adding an average of 0.2425 days or 20952 seconds per year, for an average of 31556952 seconds.
That gives slightly over 68 years for 32 bit time, putting us at 1970+68 = 2038. For 64 bit time, it’s 292,277,024,627 years. However, some 64 bit time formats use milliseconds, microseconds, 100 nanosecond units, or nanoseconds, giving us “only” about 292 million years, 292,277 years, 29,228 years, or 292 years. Assuming they use the same epoch, nano-time 64 bit time values will become a problem some time in 2262. Even if they use 1900, an end date in 2192 makes them a bad retirement plan for anyone currently alive.
Most importantly though, these representations are reasonably rare, so I’d expect this to be a much smaller issue, even if we haven’t managed to replace ourselves by AI by then.
If you’re going to correct people about Dune quotes, at least use one from the book! “The spice must flow” doesn’t appear in any of them, it’s a Lynch addition.
How much software is still running 32 bit binaries that won’t be recompiled because the source code has been lost together with the build instructions, the compiler, and the guy who knew how it worked?
How much software is using int32 instead of time_t, then casting/converting in various creative ways?
How many protocols, serialization formats and structs have 32 bit fields?
The most common date format used internally is “seconds since January 1st, 1970”.
In early 2038, the number of seconds will reach 2^31 which is the biggest number that fits in a certain (also very common) data type. Numbers bigger than that will be interpreted as negative, so instead of January 2038 it will be in December 1901 or so.
Why not just use unsigned int rather than signed int? We rarely have to store times before 1970 in computers and when we do we can just use a different format.
Because that’s how it was initially defined. I’m sure plenty of places use unsigned, which means it might either work correctly for another 68 years… or break because it gets converted to a 32 bit signed somewhere.
Y2038 is my “retirement plan”.
(Y2K, i.e. the “year 2000 problem”, affected two digit date formats. Nothing bad happened, but consensus nowadays is that that wasn’t because the issue was overblown, it’s because the issue was recognized and seriously addressed. Lots of already retired or soon retiring programmers came back to fix stuff in ancient software and made bank. In 2038, another very common date format will break. I’d say it’s much more common than 2 digit dates, but 2 digit dates may have been more common in 1985. It’s going to require a massive remediation effort and I hope AI-assisted static analysis will be viable enough to help us by then.)
My dad is a tech in the telecommunications industry. We basically didn’t see him for all of 1999. The fact that nothing happened is because of people working their assess off.
My dad had to stay in his office with a satellite phone over new years in case shit hit the fan.
My dad still believes the entire Y2K problem was a scam. How do I convince him?
Well my dad does too and he worked his ass off to prevent it. Baby boomers are just stupid as shit, there’s not really much you can do.
deleted by creator
Windows, Linux, FreeBSD, OpenBSD, NetBSD, and OSX have all already switched to 64 bit time.
Tell that to the custom binary serialization formats that all the applications are using.
Edit: and the long-calcified protocols that embed it.
So they have a year 202020 bug then
I get the joke, but for those seriously wondering:
The epoch is Jan 1, 1970. Time uses a signed integer, so you can express up to 2^31 seconds with 32 bits or 2^63 with 64 bits.
A normal year has exactly 31536000 seconds (even if it is a leap second year, as those are ignored for Unix time). 97 out of 400 years are leap years, adding an average of 0.2425 days or 20952 seconds per year, for an average of 31556952 seconds.
That gives slightly over 68 years for 32 bit time, putting us at 1970+68 = 2038. For 64 bit time, it’s 292,277,024,627 years. However, some 64 bit time formats use milliseconds, microseconds, 100 nanosecond units, or nanoseconds, giving us “only” about 292 million years, 292,277 years, 29,228 years, or 292 years. Assuming they use the same epoch, nano-time 64 bit time values will become a problem some time in 2262. Even if they use 1900, an end date in 2192 makes them a bad retirement plan for anyone currently alive.
Most importantly though, these representations are reasonably rare, so I’d expect this to be a much smaller issue, even if we haven’t managed to replace ourselves by AI by then.
I can’t wait to retire when I’m 208 years old.
Omg we are in same epoch as the butlarian crusade.
Butlerian Jihad, my dude. Hate to correct you, but the spice must flow.
Im just glad you got that reference
There are handfuls of us!
If you’re going to correct people about Dune quotes, at least use one from the book! “The spice must flow” doesn’t appear in any of them, it’s a Lynch addition.
Yes but it’s the most accessible dune quote.
How many UNIX machines in production are still running on machines with 32-bit words, or using a 32-bit time_t?
How much software is still running 32 bit binaries that won’t be recompiled because the source code has been lost together with the build instructions, the compiler, and the guy who knew how it worked?
How much software is using int32 instead of time_t, then casting/converting in various creative ways?
How many protocols, serialization formats and structs have 32 bit fields?
Irrelevant. The question you should ask instead is: how many of those things will still be in use in 15 years.
What is the basis for the 2038 problem?
The most common date format used internally is “seconds since January 1st, 1970”.
In early 2038, the number of seconds will reach 2^31 which is the biggest number that fits in a certain (also very common) data type. Numbers bigger than that will be interpreted as negative, so instead of January 2038 it will be in December 1901 or so.
Huh interesting. Why 2^31? I thought it was done in things like 2^32. We could have pushed this to 2106.
Signed integers. The number indeed goes to 2^32 but the second half is reserved for negative numbers.
With 8 bit numbers for simplicity:
0 means 0.
127 means 127 (last number before 2^(7)).
128 means -128.
255 means -1.
Why not just use unsigned int rather than signed int? We rarely have to store times before 1970 in computers and when we do we can just use a different format.
Because that’s how it was initially defined. I’m sure plenty of places use unsigned, which means it might either work correctly for another 68 years… or break because it gets converted to a 32 bit signed somewhere.
Maybe this is just a big elaborate time travel experiment 68 years in the making?