6 ms·
Year 2038 problem
- andrewstuart 12y agoSince no-one runs the code I write this is not going to matter.
- c16 12y agoI 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.
- jaibot 12y agoPredicting 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.
- TazeTSchnitzel 12y agoPHP was hacked together quickly to help Rasmus Lerdorf write his website.
- iLoch 12y agoAhh, interesting to see the PHP mindset was born with its creation: Why would I use someone else's code when I can write it myself? 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.
- Sanddancer 12y agoTo be fair, when PHP was written, there was pretty much no other code.
- emocakes 12y agoseems like someone is just learning to program...
- c16 12y agoThe 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.
- mattwritescode 12y agoI am adding this comment to my clip board. It will save me having to use it everywhere. £*() polluting the comment stream again.
- ozh 12y agoThe 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.
- mseebach 12y agoWhy would you assume that? 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?
- JetSpiegel 12y agoOh gods of efficiency, tell us how to calculate the value of a post, so that we can smite the ones lesser than a threshold.
- feketegy 12y agoBy 2038 I don't think this will matter
- jaibot 12y ago"By 2000 I don't think this will matter." - 1978
- LeonM 12y agoWell, 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...
- chrismcb 12y agoThe 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.
- mcv 12y agoBack 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.
- ygra 12y agoThe 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). [½] http://en.wikipedia.org/wiki/Epoch_(reference_date)#Notable_epoch_dates_in_computing http://en.wikipedia.org/wiki/Epoch_(reference_date)#Notable_...
- rjsw 12y agoSeveral OSs have already made the switch to 64-bit time_t, I'm typing this on one.
- ygra 12y agoThe 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.
- archgrove 12y agoAs 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. This comment is only marginally tongue in cheek.
- mseebach 12y agoIt 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.
- ygra 12y agoYou'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.
- Gilly_LDN 12y ago>> 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.
- SimpleXYZ 12y agoYou can see this bug if you have a Roku. The popular instant watch browser app shows Netflix TV shows arriving in 2038.