Year 2038 problem

http://en.wikipedia.org/wiki/Year_2038_problem

by l33tbro • 12 years ago

45 27 12 years ago

en.wikipedia.org

Since no-one runs the code I write this is not going to matter.

c162• 12 years ago

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.

jaibot• 12 years ago

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.

TazeTSchnitzel• 12 years ago

PHP was hacked together quickly to help Rasmus Lerdorf write his website.

emocakes• 12 years ago

seems like someone is just learning to program...

c162• 12 years ago

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.

mattwritescode• 12 years ago

I am adding this comment to my clip board. It will save me having to use it everywhere. £*() polluting the comment stream again.

ozh• 12 years ago

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.

JetSpiegel• 12 years ago

Oh 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• 12 years ago

By 2038 I don't think this will matter

_ei8q• 12 years ago

"By 2000 I don't think this will matter."

- 1978

LeonM• 12 years ago

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...

mcv• 12 years ago

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.

ygra3• 12 years ago

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).

[½] http://en.wikipedia.org/wiki/Epoch_(reference_date)#Notable_...

rjsw• 12 years ago

Several OSs have already made the switch to 64-bit time_t, I'm typing this on one.

ygra3• 12 years ago

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.

TheCoelacanth• 12 years ago

Adding another byte would only make it last another ~17000 years, not until the end of the universe.

weswalker125• 12 years ago

That, or he's not too optimistic about the lifespan of our universe :\

archgrove• 12 years ago

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.

This comment is only marginally tongue in cheek.

mseebach2• 12 years ago

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.

ygra3• 12 years ago

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.

Gilly_LDN• 12 years 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• 12 years ago

You can see this bug if you have a Roku. The popular instant watch browser app shows Netflix TV shows arriving in 2038.

Year 2038 problem

Related Stories