Like the y2k 'problem, we have coming the '2038' problem

[Reggie Freedman BS]

Of interest... The following was passed to me.

Snippet start-----------------------------------------
Is the year 2038 problem a real problem, or is it just a hoax in the computer science community? 
It’s a very real problem for some systems, just like Y2K was a very real problem that ended up not being much of an issue because a *LOT* of IT people put in a *lot* of hours in the decade before fixing all the problems beforehand. I personally got stuck with a large chunk of a migration project of some 12,000 users off a mainframe system onto a number of totally different systems, because upgrading the mainframe to a Y2K ready operating system was an even *bigger* challenge. You wouldn’t believe how long it takes to get 12,000 users trained on how to use a totally different email software, which was just *part* of the migration.
The problem with 2038 is that decades ago, the Unix operating system started keeping track of time in units of seconds after midnight GMT on Jan 1, 1970. And if you have a 32 bit computer, that number will overflow in 2038, just like a high-mileage car will roll the odometer over from all 9’s to all 0’s. And Linux and what became Apple’s OSX continued on with that format. Which meant that pretty much every single file on every computer that wasn’t an IBM mainframe or a Windows box had timestamps stored in that format.
And when you realize that includes things like your TV and your smartphone and your wireless router and your video doorbell and….
Yeah, the potential problem was *that* big. Fortunately, the Linux and OSX kernels are (mostly) Y2038 clean by now. But that doesn’t fix filesystems on disks that were created with 32-bit timestamps. Desktop computers won’t be the problem, fortunately. They’ll get replaced in the next 18 years, and the new boxes will be 64 bit and the filesystems will be Y2038 ready.
but there’s a lot of "embedded systems" that won’t get replaced before then. Think things like the computer that control heating and air conditioning in an office building. The computers in cars. And so on. There’s a lot of computers that live for a lot longer than 20 years. And the office building will have new owner and new tenants, and that car may have been sold - and the new owners have no idea they bought a ticking time bomb.
But just like with Y2K, the *real* problem isn’t getting the computers updated. The problem is data and the applications that read the data.
For Y2K, the problem was that you often couldn’t just go through and make a date column that had ‘78’ in it 2 bytes wider and jam a ‘19’ in front of it. It would be a flag day change - you’d have to stop *all* the software that used that data, replace it with new versions that did 4-byte years, run a job to convert *all* the data (which meant you had to have someplace to put the new copies as well as the old copies), and then finally start up the new software versions. Which is kind of a non-starter if you’re a bank and updating *all* the data would take a week or so.
And sometimes we’re talking a *lot* of data. I spent several years doing archive and backups for researchers, which included a group that did traffic safety studies by mining video from specially instrumented cars and trucks. Cars had 6 HD video cams, tractor trailers had 16 or so. All of them running anytime the engine was running - which for tractor trailers is basically 24x7. 16 HD streams. Per truck. All 500 of them.
The next thing you know, you’re looking at a half-billion files totally well over 10 petabytes - that’s 10,000 terabytes. With embedded time codes. And some of the grants that funded this say the research group has to keep the data 30 years. Which means that in the next 19 years, that group is going to have to go through and convert all those files if they contain any timestamps that roll over in 2038.
And that’s one comparatively small research project.
The only thing that’s going to save us is that financial and banking software probably won’t crap out because most of that already uses a different format for storing dates.
Snippet end-----------------------------------------
Reggie Freedman
CPI of South Florida, Inc.
386 960-7073