The UNIX epoch threat

Okay, first off…heh, I know I’ve not been updating this like I’ve said I would…but, with work, personal life (drama), and other stuff…heh, yeah.  But, I’m going to try to be a better informer.

I bet you’re wondering what I’m even talking about.  Well, here’s what this (small) post is about.  In the (not so, depending how you view it) coming years, all 32-bit operating systems that tell time based off of the UNIX epoch time (which is defined as “00:00:00 UTC on January 1, 1970″ by the Wikipedia article on it) will no longer be able to do so from January 19, 2038, on.  The reason being is that epoch is stored as an unsigned 32-bit integer, which means it can only increment so high ((2^n) - 1, or 4.294967295e9 [(2^32) - 1]), before it overflows.  Even though that seems like an awfully long time for something dangerous to happen, businesses that use operating systems or software that base time off of this format should consider what to do.  This will have a dramatic effect on things such as billing software, installation databases, etc…

Off topic, slightly, but I know this isn’t the most informative article written here…but, there’s really not much else to write about this topic, for the simple fact of: 1)  the solution is rather simple…use a 64-bit (operating) system; 2)  by the year 2038, who isn’t going to have at least a 64-bit (operating) system?  That doesn’t necessarily clear the air for software, but by then the problem, I believe will already have been extinguished.

However, this would be an interesting situation at my current work force…hehe.  The people who do use Unix are pretty much all running software that depends on time in some manner or another…and, well, we all know how Unix keeps track of time.