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.
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.
