Why should a Java programmer care about year 2038 bug?

Question

Year 2038 Bug is all over the web, But this seems to be a unix issue. How will this affect java Date ?

Clumsy

Will there be another Roland Emmerich movie about that one? – Unbonnet

It's not a bug. Everyone knows the world will end by 2038. The only question is how. My guess is zombie plague. – Echolalia

Should not bother anyone .. as we all know, earth ends in 2012 anyways. Write some cool stuff instead – Turgeon

@Turgeon - no no - there will be survivors in the 2012 thing. But they won't last long... – Echolalia

Why should I worry about it now, when I can get paid 10k a day to fix it in 2037? – Trinette

@skaffmann in 2037, 10k will probably get you a hamburger and fries :-) – Promethean

@ S.P.Floyd - seanizer, that would be in 3D... lol.. – Schweitzer

@sasivi: It is not a Unx issue. It is a "32-bit Unx" issue and even not all 32-bits Unx are affected (only the one counting milliseconds since the epoch using 32 bits are affected and, shocking revelation, it is possible to count on 64 bits even on 32 bits CPUs!). If you think there will be a lot of 32 bits Unx (still counting time on 32 bits) around by 2038 I suggest a visit to the closest mental hospital ; ) – Antalya

@ all: it is really scary to see all these comments and answers stating: "all OSes will be 64 bits by then" as if counting on 64 bits wasn't possible on a 32 bits OS. Mindboggling. – Antalya

@Webinator, actually, your comment is inaccurate. time_t is required to count seconds, not milliseconds. – Ruthenious

You still want to use Java in 2038? That would be lame ... – Juryrig

Answer 1

What makes you think it does? Java's Date class stores a 64-bit long (not 32-bit, as with Y2K38). It also stores milliseconds, which decreases the range, but only slightly (equivalent of ~10 bits).

In Java, we have the year 292278994 bug.

Ruthenious

+1 - but surely Java on Unix sometimes needs to talk dates with the underlying O/S. Unlikely a real issue (until 2038), but maybe worth a mention. – Echolalia

@Steve, true, but I think the question is specifically about java.util.Date, not anything involving time_t. – Ruthenious

How does a Java app get it's time in the first place? Java might be able to handle dates well but GIGO might still be a problem. – Tompkins

@Tompkins - yes, but the current date won't be 2038 until 2038. So for now, what's the problem? Likewise for e.g. file dates - unless you're sharing files with a time-traveller. So - unlikely a real issue until 2038. – Echolalia

@Steve314: I was (and am) agreeing with you. – Tompkins

@Tompkins - but you assume I agree with myself? I play devils advocate a lot. Mind you, the trouble with playing devils advocate is... – Echolalia

Answer 2

Java and times aren't restricted just to the Date class.

Where do dates/times often come from? Often from System.currentTimeMillis, which is a native method. It's typically not implemented in Java. The return type is a long, but that means little, since the native method can return any value that simply fits into a long.

It will all depend on the OS, and its implementation of the JRE.

To rely on the presence of 64-bit systems might be naive, since apparently there are many embedded systems that are 32-bit, and will continue to be.

In general, Java is exposed to the 2038 issue.

Coonhound

Answer 3

I don't believe it will impact the Java Date class as for as the programmer is concerned. It's already using 64-bit values. I can see it being a problem if you're using a data store that still uses 32-bit values. I don't expect to see too many 32-bit OSes around in 27 years.

Ilyse

That haven't been patched to fix this. I imagine some embedded systems might still use 32-bit. – Arlindaarline

I'm quite sure that 28 years from now not even embedded systems would use 32-bit – Television

@Goran - washing machines may still use 8 bit, just as they probably do now. Not sure that clothes or dirt are going to change much in the next 28 years. But if something does change (digital rights management to prevent you using unauthorised detergents, maybe?) then a 32 bit Unix box may be needed. – Echolalia

Answer 4

This is not really an answer. But some posts have gotten it right. Java is 2038 compliant, but not 10000 compliant (if you put a long into the Date constructor that represents something after 9999, it will not work and return some weird number), but yes, 2147483648 is definitely not the maximum allowed value in Java's Date class.

Absquatulate

Answer 5

This is probably a leftover from the old C days when the date data types rolled over in 2038. Might be a problem with some really old apps, but not for Java. Yawn.

Hurry

The answers above show that this is a much subtler problem than that, and Java is exposed to it, since it is not perfectly insulated from the underlying O/S for many common paths. – Laminous