Why should a Java programmer care about year 2038 bug? Why should a Java programmer care about year 2038 bug? unix unix

Why should a Java programmer care about year 2038 bug?


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.


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.


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.