Year 2038 Bug is all over the web, But this seems to be a unix issue. How will this affect java Date ?
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.
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.
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.
来源：https://stackoverflow.com/questions/4313707/why-should-a-java-programmer-care-about-year-2038-bug