We should start worrying about Y2K38 now

The Linux kernel always stores and calculates time as the number of
seconds since midnight of the 1st of January 1970 UTC regardless of
whether your hardware clock is stored as UTC or not. Conversions to
your local time are done at run-time. One neat thing about this is
that if someone is using your computer from a different timezone, they
can set the TZ environment variable and all dates and times will
appear correct for their timezone.

If the number of seconds since the 1st of January 1970 UTC is
stored as an signed 32-bit integer (as it is on your Linux/Intel
system), your clock will stop working sometime on the year 2038.
Linux has no inherent Y2K problem, but it does have a year 2038
problem. Hopefully we'll all be running Linux on 64-bit systems by
then. 64-bit integers will keep our clocks running quite well until
aproximately the year 292271-million.

via linuxsa.org.au

Remember Y2K almost 10 years ago? It didn't make too big of a splash because of the media hype - at least me - encouraged companies to make sure things just worked. I like to think of that as the "odd man out" syndrome since no company wanted to consistently be cited as the example of the "big Y2K failure."

Well, we have another computer time death march coming up in 28 years in 2038. I really do hope that we're all running 64-bit operating systems by then, but considering big business it still running 1970s mainframes... I really do wonder. So let's start today by encouraging or in my case demanding 64-bit support of software and operating systems.