Year 2038 problem
en.wikipedia.org
en.wikipedia.org
This comment is only marginally tongue in cheek.
Mind you, that's not PHP's fault - seems that a lot of novice programmers take this approach, with PHP being an easy beginner language.
I still don't know enough about OSs to know how feasible it is, but back then, the move towards 64 bit OSs seemed like a great opportunity to make this change. Maybe when we move to 128 bit systems we can finally do this? I'd like not to postpone this until the last minute like last time.
The question probably is why a 32-bit type was deemed sufficient back then, but as others have noted, it is very hard to anticipate the lifetime of software and it was a pragmatic tradeoff between anticipated OS lifetime and necessary storage space. There are other problems as well, though. time_t is a type designed for keeping track of the current time of a computer system, therefore an arbitrary cutoff point in the past is sufficient. But then it got used for all kinds of other things – storing people's birthdays, using it as internal representation for a DateTime type, etc. Those have been problematic ever since because a possible date range of 1901–2038 is not necessarily sufficient for those use cases.
Fact is, though, that for keeping time in a computer a simple scalar that counts units since a reference date is the easiest and most efficient solution. Over time there have been plenty of such reference dates (epochs) [½], the most notable these days probably Unix (1970-01-01), popular spreadsheets (around 1900-01-01) or Windows (1601-01-01).
[½] http://en.wikipedia.org/wiki/Epoch_(reference_date)#Notable_...
Basically beginning with XML in the 1990s, the "modern world" is rapidly converging on accepting full, textual dates (preferably in one of the ISO 8601 formats) in any but the most private and short-lived of formats (protobufs and the like). These textual formats are obviously not vulnerable to the 2038 issue, so preparing for 2038 will be significantly easier, as it can be done unilaterally, without all the coordination overhead.
I do hate bugs that only pop up at 3am in the morning.
As I understand it, the problem is more in the compiler/interpreter than in the storage medium. Say, your using mysql to hold an int field - to alter the storage allocation to include more bytes is simple, even trivial. It is the language which will need to be updated to understand that it is using an unsigned integer for the unix epoch.
- 1978
I do know some people (even those who had no technical background or whatsoever) that made ridiculous amounts of money by "consulting" about the y2k problem.
My retirement plan is consulting on the y2k38 problem. However, as opposed to the y2k witch-hunt, this problem is very real. Preparing systems to be y2k38 ready actually requires work to be done...
In all seriousness, comments such as this degrade the community and add no value. Please reconsider next time.
Do you have a list of other topics that are so obvious that no Hacker News community member can possibly gain any value what so ever from reading about them?