Funnily enough it is a massive problem which is already starting to bite now. For obvious reasons I won't name any names, but several large global
banks have already seen failures in systems that calculate mortgage interest over 25 year periods (and longer on commercial mortgages).
Similarly, almost every single core router on the Internet uses a signed 32bit integer for date stamping data packets for routing.
Is it really serious? Yes, it absolutely is. Does a 64bit (or 128bit or whatever gets invented in the future) system solve this problem - no.
The real problem is when Unix was created - and indeed most of the operating systems in use today - it was assumed that in 50 odd years time something
new would replace them.
This was correct of course, but two issues remained - nobody changed how date and time is handled because they didn't want to break compatibility and
every other OS was written to be loosely compatible with things like date standards.
There are several ways of fixing it - but the problem is that there is no "one right way" to do it. Changing date to an unsigned integer fixes the
issue on *nix, but breaks everything that interconnects it. Changing values to a 64bit integer (signed or unsigned) means many systems - even some "64
bit" systems can't then handle the long word in one cycle which breaks interrupt timings and just setting a new epoch means nothing before the new
epoch is considered valid data.
So it is a very real challenge - however many people are genuinely working on the problem.
The Y2k problem was really only a 'non problem' because many industries (especially my industry - telecoms) started locking developers into rooms to
'fix' the issues about 6 years before it. By the time mass media was reporting the Y2k bug and predicting the end of the world, practically all
essential systems had already been patched or workarounds were in place - the biggest risk were smaller 'custom' systems generally used for accounting
and the like which were written by small independent outfits, many of whom ceased to exit long before any issues were known about.
So yes, Very real problem, much greater problem than the Y2k bug and a lot more technically challenging (the signed 32bit date format was how we
fixed Y2k, as before that date was always an unsigned 32bit format so we can't use that trick again) but...
...no doom porn - too many of us are working on the problem. The worst case scenario is generally considered to be with embedded devices that are
dependent on date and time information. From a consumer point of view, worst anyone will see is garbage dates in log files on unpacked systems
(Source : I was one of the monkeys at British Telecom fixing Y2K issues way before Y2k... and it was possibly the most peaceful shift I ever worked on
31st Dec 2000 because the fixes worked and were tested at least 2 years before!)