The Y2038 problem is similar to the Y2K problem. We’re exactly in between both about now. Both are 18 years away, in either direction. While Y2K is over and was obvious to everyone, Y2038 is not.
The issue here relates to a representation of date and time in Unix systems, and is therefore sometimes referred to as Unix Y2K. The root is the convention to store date and time information as 32bit unsigned integer in such systems. This means, possible values are limited. Time-differences in seconds, starting from 01.Jan 1970 cannot span beyond 03:14:07 UTC on 19 January 2038.
The Y2038 problem will make all calculations beyond this date impossible, until migrated to another representation. At the time being, this seems far away. However, the problem casts its shadows already. Industries, in particular financial markets, often rely on long term forecasts.
Governance issued treasury bonds come with with the longest maturity. Often twenty years, sometimes thirty years. Calculations for complex, long running financing models easily try to estimate returns 20 years and beyond into the future. This is already beyond the problematic date that Y2038 brings. The code to run these calculations is typically complex and stable. Sometimes, it is as old as from 1970. Back then, this date-representation Unix engineers introduced this approach. 32bit covered a long period. John Femellia has a thread, over at Twitter, telling a story about the upcoming issues today.