Why should a Java programmer care about year 2038 bug?

允我心安 提交于 2019-11-30 11:59:49

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.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!