Year 2038 Bug is all over the web, But this seems to be a unix issue. How will this affect java Date ?
If you have read How Bits and Bytes Work, you know that a signed 4-byte integer has a maximum value of 2,147,483,647, and this is where the Year 2038 problem comes from. The maximum value of time before it rolls over to a negative (and invalid) value is 2,147,483,647, which translates into January 19, 2038.
Solutions. There is no universal solution for the Year 2038 problem. For example, in the C language, any change to the definition of the time_t data type would result in code-compatibility problems in any application in which date and time representations are dependent on the nature of the signed 32-bit time_t integer.
Representing timeMost 32-bit Unix-like systems store time in a 32-bit (4 bytes) signed integer and are thus able to represent a range of 136 years, from 1901 to 2038. Other 32-bit implementations use unsigned integers and can represent years up until 2106, but cannot handle dates before the epoch.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With