5 years ago, I witnessed the historical moment where time passed by, marking the start of a new millennium. There are a lot of news about the Y2K bug before that, about how it will causes impact to our every day life. But well thanks to those people who done the preparation, fixing and patching on the electronic devices that we rely on, I stepped into the year 2000 without having a single trouble, just that I need to remember not to write year 1999 instead of 2000 when filling up forms.
So, now what? I'm working on some sort of birthday reminder thing in PHP and I got frustrated when it comes to storing a person's birth date. First of all I don't like to use MySQL datetime date type, I prefer using
unix epoch which can be easily generated using php time() and mktime(), saving me the steps to converting the format. However unix epoch is only valid from
January 1 1970 00:00:00 GMT onwards, making those people who born before 1970 invalid. So I do some google-ing to find out why the developers of Unix or even PHP refuse to start unix epoch from, say, year 1600 ? (Windows Win32 FILETIME epoch is at January 1 1601 00:00:00 UTC, Im guessing windows is using unsigned 32-bit, because windows don't work with negative timestamps... lazy to do the calculations...) Before I got my answers, I dsicovered some interesting news.
After the Y2K problem, are you aware of the next coming bug similar to Y2K's one ?
The Y2038 problem
In computing, the year 2038 problem may cause some computer software to fail in or about the year 2038. The problem affects programs that use the POSIX time representation, which represents time as the number of seconds since January 1, 1970. This representation is standard in Unix-like operating systems and also affects software written for most other operating systems because of the broad deployment of C. On most 32-bit systems, the time_t data type used to store this second count is a signed 32-bit integer. The latest time that can be represented in this format, following the POSIX standard, is
03:14:08 UTC on January 19, 2038. Times beyond this moment will "wrap around" and be represented internally as a negative number, and cause programs to fail, since they will see these times not as being in 2038 but rather in 1970 or 1901, depending on the implementation. Erroneous calculations and decisions may therefore result.
Using a 64-bit architecture will solve this problem, delaying the date problem to about 300 billion years later. To be more precise, it will happen on
Sunday, 4 December, year 292,277,026,596. After 292 billion years later, maybe a 128-bit will be used which hmm...really isn't our business anymore. Who cares what will happen after 292 billion years eh ? I don't even really care if my weblog will crash or not in year 2038... hehe... who cares anyway ?
source:
http://en.wikipedia.org/wiki/Unix_epoch
http://en.wikipedia.org/wiki/Year_2038_problem
