I would argue that it is in everyone's interest to care about these sort of things. Not only is interesting, it's also important to understand how and why it happens.
Predicting code use in advance is hard. Linux was a casual side project not meant to be taken seriously; Javascript was hacked together in a few weeks.
The HN community thanks you for this well thought out and high quality comment. You have clearly shown us some knowledgeable information for which we are truly grateful.
In all seriousness, comments such as this degrade the community and add no value. Please reconsider next time.
The comment isn't interesting but the question behind it is quite legit: it's odd to say the least that a post like this would surface on the front page, here where you'd assume most if not all are already aware of it. It'd be interesting to know why.
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?
Well, seriously, how much did it really matter in 2000? How much systems from the 70's were still in use in the year 2k? And how much of them actually failed? Even my IBM 8086 was y2k compliant.
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...
The y2K problem was very real as well. A lot of the systems were still in place, and a TON of work happened at the end of the 90s to solve the y2K problem. The fact that not many of them failed showed the success of the Herculean effort to solve the problem.
Back when I first heard about this, I wondered if it wouldn't be possible to simpy add an extra byte to the date. That would last us until the end of the universe.
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 move to a 64-bit is sufficient, or at least a 64-bit time_t suffices for the very foreseeable future. Adding just one byte doesn't gain you much because neither CPUs, nor most programming languages deal well with a 36-bit type – you'd end up with a 64-bit type anyway in most cases which is nicer to handle.
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).
The problem is most likely with legacy and embedded systems. The sort that are running somewhere for decades, unnoticed. Until they fail some day and panic happens. And they're not easily upgradeable either.
As an early 30s programmer with low-level backend experience, I'm relying on the 2038 problem to form the backbone of my retirement income. I've already started writing the business plan for my migration consultancy.
It seems that Y2K was mostly painful because tons of data interchange formats specified two-digit years and fixing it meant getting it fixed at all endpoints at the same time.
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.
You'd be surprised in how many places unixtime crops up. I'd really prefer ISO 8601 (especially becase it's a sane format, human-readable and supports time zones) though.
>> The furthest time that can be represented this way is 03:14:07 UTC on Tuesday, 19 January 2038 (2147483647 seconds after January 1st, 1970).
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.
27 comments
[ 2.4 ms ] story [ 67.8 ms ] threadMind you, that's not PHP's fault - seems that a lot of novice programmers take this approach, with PHP being an easy beginner language.
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?
- 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...
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_...
This comment is only marginally tongue in cheek.
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.