Unlike the Y2K bug, which was mostly hype and only affected a handful of poorly written programs, the Y2038 issue could have some potential for impact. Anything which uses the time_t, which is the recommended method of keeping track of time in programs, will fail on systems where it maps to a signed 32-bit integer. So even properly developed software, including operating systems, will fail.

There is a lot of software from the 60s-90s still running on modern mainframes and servers within virtual machines (VMs) that will need to be reprogrammed, notably a lot of old stuff programmed in COBOL for the finance and banking sector.

Most mainframes and UNIX systems have switched to using signed 64-bit integers to store time_t, which is what the article is joking about in a tongue-and-cheek way. So yeah, we're good for another 293 billion years if you're using that in your software.

In a decade or two, even that might be pushed out. It is a matter of time before processors used in mainframes, servers and workstations switch from using a 64-bit integer as their native data type to either 128-bit or even 256-bit. It is usually faster and easier to manipulate a value stored as the native data type than something smaller, so time_t might get bumped in size again. Some people propose that when we get to that point, we might switch from the number of seconds since 1901 to the number of milliseconds since 1901.

/you can read about more time bugs here//the mid-2030s will be a boom time for COBOL programmers

Windows whatever-they-call-it-these-days is based on Windows NT which is based on VMS which does not count seconds, but tenths of microseconds. According to Wikipedia the VMS time counter expires at 31-JUL-31086 02:48:05.47.

Meh? time_t is a C library standard, though it can be 32 or 64 bit, referenced from the Unix epoch. Starting at least with VC++ 2005, time_t is 64 bit, though a coder can override that at compile time. Sure NT shares some VMS genes, but I'm not aware that VMS-style time functions exist in user APIs. There are a wealth of time functions available with higher resolution than that of time(), but unless your app is doing something special, it is wise to use time()

Unlike the Y2K bug, which was mostly hype and only affected a handful of poorly written programs, the Y2038 issue could have some potential for impact. Anything which uses the time_t, which is the recommended method of keeping track of time in programs, will fail on systems where it maps to a signed 32-bit integer. So even properly developed software, including operating systems, will fail.

The Y2K bug was NOT a lot of hype. It was just well-managed, surprisingly. And caught early enough to fix for.

The Y2038 bug will be naturally fixed as integers grow to 64-bits.

I had many long nights in '97 and '98 that attest to there having been an actual problem that industry managed to take seriously, for a change.

It was nice that the first things to be affected were long-horizon dates. E.g. when credit cards started failing because they looked like they had expired in 1900, there was still plenty of time to reissue cards that expired in 1999 instead, and then fix the code before dates in 2000 became necessary, rather than merely convenient. But since there were failures, it was easier to convince Management that the massive effort was really needed.

I remember a few systems that were fixed to use a 4-digit date before they were fixed to display a 4-digit date, so you had ugly things like "year of graduation" showing up as either 19 or 20 for a while. But because the underlying data had been corrected, it was only a cosmetic issue.

Unlike the Y2K bug, which was mostly hype and only affected a handful of poorly written programs, the Y2038 issue could have some potential for impact. Anything which uses the time_t, which is the recommended method of keeping track of time in programs, will fail on systems where it maps to a signed 32-bit integer. So even properly developed software, including operating systems, will fail.

The Y2K bug was NOT a lot of hype. It was just well-managed, surprisingly. And caught early enough to fix for.