The year 2038 might not have an impact in Perl directly. But there are quite a few file formats (or variants) around that encode dates in 32 bits.

From what i dimly remember, at least older JPEG versions used 32 bit Unix timestamps in the EXIF metadata. So even something trivial like sorting your photo archive by age might need some additional code.

And all those external APIs, especially to embedded systems and microcontrollers, might need a closer look. Those things are often around for ages. For context: Until a few years ago, some highrises in U.S. cities still had to run AC-to-DC converters in their basement tol run the elevator motors installed before WW1.

If you thing your "shiny new" elevator vom 2001 supports 64 bit, well, think again. Those things often have just enough smarts to refuse service if you miss the maintenance interval, but you might need special software that resets the maintenance date acdcording to the 32 bit overflow after 2038. And even if the elevator got a firmware update, the "maintenance reset" software on the engineers laptop might still run on TinyPerl 5.8 ;-)

AFAIK, the Year 2000 problem was nowhere near as catastrophic as many had predicted.

It was not catastrophic because of the hype. For example, the small factory I worked at as an intern had a "Y2K Intern" role. As in, they approached the local university and specifically hired co-op students over the course of about 1.5 years to run all their factory software across the Y2K boundary. This would not have happened if the Y2K scare was not looming large over the managers.

In that sense, the scare over Y2K was a success story. The engineers all knew that shit was going to hit the fan, and collectively alarmed the managers of the world to do something about it.

It was not catastrophic because of the hype.

Yes, but ... - As usual, there was a lot of nonsense, and people earned a lot of money with nonsense.

Is your mechanic 0-60 min cooking timer Y2K compatible? How about your electronic one? Yes, it's only job is to count down from at most 60:00 to 0:00, and it does so whatever date is. It has no idea of the date. But still, people sold them with a "Y2K compatible" badge.

Same with simple clocks counting only seconds, minutes, and hours, but no days, months, or years.

Same with keyboards, mice, printers, floppy drives, floppies.

Many people offered ther services as "Y2K consultants". Some of them couldn't tell the difference between a mechanical type writer and a PC, but that did not prevent them from consulting bullsh*t and demanding money for worthless Y2K stickers and certificates.

---

I still remember checking servers and clients for their behaviour around the roll-over from 1999-12-31 23:59:59 to 2000-01-01 00:00:00. On recent hard- and software of that time, the roll-over was no problem at all. I even was contacted by the user of my first sold software, asking if it was Y2k compatible. (Yes, it was, years before Y2K. I dislike the usual year mod 100 notation, so all of my software always uses the full year.)

Some clever people have build replacement RTCs that could be plugged into all PCs with an ISA slot (almost all at that time). That RTCs did properly roll over from 1999 to 2000, and came with their own little BIOS to handle the roll-over. They sold pretty well, even if almost no PC needed them. Generic BIOSes and RTCs could handle the roll-over without any support.

---

My guess for the Y2K38 problem?

Technically, I don't expect big problems. It affects only system using Unix time stamps , and only those where time_t is a signed 32-bit integer. 64 bit systems use a 64-bit signed integer for time_t, and more and more systems are 64 bit. And their share will grow even more until 2038. So, it is a legacy systems problem. Linux changed time_t to 64 bit even on 32-bit systems years ago, so no problem there. I think the BSDs already did the same. So, 2038 will be a problem for only for systems that are considered legacy NOW. Systems installed today will be "old" or "legacy" in 2038, and they won't have a Y2K38 problem. (Of couse, some applications might still use a 32 bit timestamp defined like time_t, but not defined as time_t, even on 64 bit systems, and they WILL fail. But the OS itself shouldn't have a problem.)

In the public, it depends. As explained, using 64 bit systems should mostly solve the problem. It may gain some "computers will kill us if we don't fix the time_t problem" momentum, but I doubt journalists will fully understand the problem. So we will probably face a some nonsense, but because Y2K went so smooth, I hope that nobody (except for some IT expoerts) really will or needs to care about 2038.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Yes, I'm ignoring all the social side effects of the hype, which did create a mess. The alarm was meant for the business decision makers, not the general populace to take shelter, but a lot of the latter happened. I stand by my point that a lot of bad things may have happened without the hype, though, especially related to billing systems coded in COBOL, which was fairly common. Even a lot of newer DOS software for console had problems just because of the console/terminal mentality of squeezing information onto the 80 available columns of screen.

I also agree that 2038 won't likely have problems, because the problems have been solved so far in advance. I can't claim to be in the clear myself, though, because we have an (fairly important) app we wrote for a customer about 15 years ago using 32-bit MySQL 5.0 and they decided it was good enough to not budget any time to improve it since then. They pay us to keep the server alive and make backups, but not to upgrade anything. If we're both still in business 12 years from now, we'll need to have a talk with them about finally upgrading that. A 2038 scare among management might help produce budget for that.

Actually, I just looked it up, and even the latest MySQL 8 still limits TIMESTAMP columns to 32-bit. So anyone who doesn't realize that could still be creating new app schemas with a 2038 bomb waiting to go off, even for a modern 64-bit software stack.

What I really like about XP is that when I click on Microsoft Word, it pops up immediately. It may take 1 second, but it's almost instant. On Linux, when I click on LibreOffice, I have to sit there and wait for half a minute for it to finally be ready so I can type.

What makes Windows XP unique is that it supports HTA applications and JScript which don't work on Linux at all. For example, Windows has the ability to embed JavaScript apps into the desktop. In Windows 7, there were JavaScript apps called "gadgets." There was a clock app, a weather app, and various others. I modified the clock app slightly, so it said the time out loud at the top of every hour. With some tweaking, these apps can also run on XP. I also wrote various registry tweaking tools in JavaScript which increase Windows performance and customize my desktop. I have dozens of JavaScript programs that I have written over the years. Some of them rename files, search and replace strings, tweak Windows, create playlists for Windows Media Player from my music folder. I guess, I could convert them to Perl, but that would take quite awhile. By switching to Linux, all my Windows knowledge will be useless, and I have to start from zero. Well, not entirely. See, one of the reasons I chose to learn PERL is because it allows me to control Linux. If I open the terminal window and type in "perl -v" and it shows that Perl is installed, I feel such a relief! Whether I'm on a Raspberry Pi or Apple or Linux, when I see that Perl is installed on the system, I know, at least, there is ONE familiar thing in this strange system. :)

What I really like about XP is that when I click on Microsoft Word, it pops up immediately. It may take 1 second, but it's almost instant.

One second is not exactly instantly ...

On Linux, when I click on LibreOffice, I have to sit there and wait for half a minute for it to finally be ready so I can type.

Are you comparing apples and oranges? Linux is - strictly speaking - just an OS kernel, no graphical user interface. Linux distributions come with a wide range of GUIs. You can easily make a Linux distribution look like MacOS, Windows, or a Sun workstation. Or something completely different. Often, Gnome is the default. It is one of the GUIs that has a lot of fancy effects, is at least partially optimized for using with a touch screen, and I absolutely do not like it. It is fat, and slows down everything. But Linux gives you freedom of choice, just uninstall Gnome and replace it with something lightwhight, like Xfce. It looks like a desktop from the last century, but it also works well on hardware from the last century. Very limited visual effects, no "oh sorry, you have to wait for the end of this useless visual animation before resources for your desired action are available". And suddenly, your old computer feels fast again.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)