Instead of clicking on an unknown blog, how about this?
https://www.quora.com/What-is-the-Unix-32-bit-time-overflow
It’s a problem that affects UNIX systems with a 32 bit time_t data type.
The data type time_t is defined in < sys/types.h > as an integer type; the size of this type is unspecified, but it’s not specified as an unsigned type, and is therefore signed.
If the size of your integral typed (char, short, int, long, and long long are all integral types) time_t is 32 bits in width, your computer has what’s called the Year 2038 problem - Wikipedia.
The UNIX epoch is 1 January 1970. Time in time_t is measured in +/- seconds relative to that date.
This means that the 32 bit signed integer value will roll over to a negative number on 19 January 2038 at 3:14:07AM GMT, which is exactly 2,147,483,647 seconds after the epoch, and suddenly it will be 13 December 1901.
It’s not a problem on most modern UNIX systems, since time_t in modern systems is defined as a 64 bit integral type.
I personally fixed this in Mac OS X in 2004, while employed as a kernel engineer at Apple; in doing the 64 bit kernel work, I made the arbitrary decision to change the type of the field from int — 32 bits — to long — 64 bits — specifically because of this problem.
It was arbitrary, because, as a kernel change, there was no 64 bit user space at the time.
Since it’s unlikely that 32 bit systems will exist in large numbers in 2038 anyway, most other systems will have probably avoided the problem as well.
Note that this issue only impacts you if you have a 32 bit time_t, and you are using it as data type that gets serialized to storage.
Since the best current practice on storage types was a text representation for dates, since — well — forever, only programmers who ignored this at their peril will have written programs that actually suffer from this problem.
If there were a lot of these programs, then the problems probably would have been hitting us already for programs that had future dates that started out overflowed. One example might a 30 year mortgage with an incept date after 2008, which would push it into negative territory (note that I had fixed Mac OS X four years prior to that date).
Like Y2K, Y2038 is likely to be a non-event, other than a bunch of UNIX geeks having “End Of The World” parties the weekend before that Tuesday rolled around.
I suspect there may also bee some “inside joke” T-shirts sold as the day approaches…
The World Ends On A Tuesday
Pass It On
The link I posted was just a countdown clock a friend of mine sent me. I thought it was a cool vanity topic and a bit of humor to inject at a time a great focus on November 3rd, 2020. Looking ahead 18 years seems like an eternity but an interesting topic none the less
“non-event”
Exactly. We’ll take care of it beforehand, and that’ll be the end of it.
Luckily, most of the people who make these statements now will either be retired ...or paid handsomely to fix the issue.
It's not that the old systems will be plentiful, it's that the ones that are left will have been kept in place for some very specific reasons, usually because a replacement is considered cost prohibitive for some reason that could have been avoided decades ago.
A disturbing number of computer systems we rely on daily (health insurance, social security, taxes, banking) still use COBOL code originally written 40+ years ago... and will keep doing so as long as they can still find chips that process the instructions. It's not the old code that's the problem though, it's the 40+ years of business rule changes, workarounds, edge cases, and incorporating code from acquisitions that makes the code hard to work with. I wouldn't bet much money that those systems will get fully replaced by 2038, bit I will bet that many of the guys in their late 60's and 70's who already retired once will be willing to come in to work in another decade and a half to fix those remaining systems like they're doing now.