2038 is The End Of The World As We Know It. Technically it is the end of an epoch, or perhaps The Epoch. The Epoch is the range of dates starting at January 1, 1970 00:00:00 GMT and ending at January 19, 2038 03:14:07 GMT, used by Perl's time(), Java's Date class, and C/C++'s time() (and I suspect others). This past January 9th was the half-way point of The Epoch's usability. (Microsoft Windows and MS-DOS's epochs end in 2048 because they started in 1980, but they use the same 32-bit date storage as The Epoch.)
So why does this matter to me, you ask? Because if you write code that reads or writes dates, that code will fail in 34 years.
34 years is a long time, you may say. I used to think so, too. Then one day I realized that regular expression code I wrote more than 20 years ago was still shipping in a product that shows no signs of being near the end of its lifecycle.
Code for handling dates, whether for reading, writing, or calculating dates, will start failing when it is asked to handle dates beyond the January 19, 2038 03:14:07 GMT lifespan of The Epoch. This doesn't affect just those of us who work on Web applications, although I will be interested to see how weblogs and online newspapers handle 2038 -- I would hate to lose the access to the contributions of my fellow use.perl.org bloggers, Jerry Pournelle, or Dave Winer over a date error.
January 19, 2008 03:14:08 GMT is important, as you cannot add 30 years to that time without exceeding the limits of The Epoch, thereby affecting some mortgage calculations (30-year mortgages are common here in the States). (Long-term bond maturation calculations (among others) will also be affected by the end of The Epoch.) As a practical matter, 30-year mortgage failures from The Epoch should start occurring around February 20, 2008, as you can't use Epoch dates to calculate the last mortgage payment date (if I have performed the calculations correctly). 2008 is only four years away. (There have been 50-year mortgages originated in Japan within the past 15 years -- but there may not be any programs using Epoch dates that had to handle those mortgages.)
January 19, 2018 03:14:08 GMT will also be important here in the States at least, as you cannot add 20 years to that time without exceeding the limits of The Epoch, thereby affecting 20-year mortgage calculations. 2018 is only 14 years away which should be well within the date range that software engineers (Perl or otherwise) should be considering when creating or updating date-handling code today.
But I Feel Fine (thereby completing the R.E.M. reference), as my new code uses non-Epoch dates. New Perl code will use DateTime, and my latest Java code already uses the Java GregorianCalendar class. (I still need to research date alternatives for C++ and C.) I confess to feeling a little like Ed Yourdon, who (if I remember correctly) started warning about Y2K problems in the early 1990s, long before the problem really caught the attention of software engineers and IT managers.
If your code (old or new) handles dates, you need to be concerned about 2038 ITEOTWAWKI (2038 Is The End Of The World As We Know It). Perl now has DateTime, which looks like it will work well for most date applications. Readers using other languages will need to do some research (except for Java GregorianCalendar, as noted above). Happy date-handling!