Regarding year-2038 bug fix ...

Hi,

Please let me know in which release of JDK the fix for year-2038 bug is included. Also is this problem resolved in JDK1.5 release.

[ problem : year-2038 bug is described as here in this web site..

http://www.2038bug.com/

]

thanks in advance..

[285 byte] By [Suresh_Hegdea] at [2007-11-27 10:28:25]
# 1

I haven't done the math, but assuming the numbers are correct, it won't be an issue for java.util.Date for a long time. The article speaks of using 4 bytes for seconds since 1/1/1970. However, java.util.Date uses 8 bytes (a long) for millis since 1/1/1970, which is good until about the year 290,000,000.

jverda at 2007-7-28 17:51:32 > top of Java-index,Core,Core APIs...
# 2

Hi,

We were using JDK1.3 for compiling our sources and we come across this problem recently.

Then how do we overcome this problem?

it would be great if i find any suggestion for this.

Thanks,

Suresh

Suresh_Hegdea at 2007-7-28 17:51:32 > top of Java-index,Core,Core APIs...
# 3

> Hi,

>

> We were using JDK1.3 for compiling our sources

Which uses long in java.util.Date, as I described above.

> and we

> come across this problem recently.

What do you mean? Can you provide sample code and output that demonstrates what problem you're having?

jverda at 2007-7-28 17:51:32 > top of Java-index,Core,Core APIs...
# 4

Even if there was a problem, Sun have released a patch, it's called upgrading!

You can't expect a company to keep making patches for much older versions of their software, that would be like demanding Microsoft patch your Windows 95

alanmpa at 2007-7-28 17:51:32 > top of Java-index,Core,Core APIs...
# 5

anyway, if you run your software on a 32 bit *nix based machine the operating system clock will supply your software with incorrect dates past 2038.

Nothing a JVM can do about that, contact your operating system vendor.

jwentinga at 2007-7-28 17:51:32 > top of Java-index,Core,Core APIs...
# 6

> anyway, if you run your software on a 32 bit *nix

> based machine the operating system clock will supply

> your software with incorrect dates past 2038.

> Nothing a JVM can do about that, contact your

> operating system vendor.

Hopefully that will be addressed in the next 30 years.

jverda at 2007-7-28 17:51:32 > top of Java-index,Core,Core APIs...
# 7

> Hopefully that will be addressed in the next 30 years.

Who knows. I do know that I hope to retire around that time so it'll be somebody else's problem :)

jwentinga at 2007-7-28 17:51:32 > top of Java-index,Core,Core APIs...
# 8

Sorry, I'm too busy preparing for Y3K to work on the 2038 problem (and finishing up my Y2K fixes). If you do fix 2038, you might as well fix that 2048 problem.

George123a at 2007-7-28 17:51:32 > top of Java-index,Core,Core APIs...
# 9

Hello. If you don't mind can you plz give little more information about y3k problem? please.

YShashidhara at 2007-7-28 17:51:32 > top of Java-index,Core,Core APIs...
# 10

!!!

ejpa at 2007-7-28 17:51:32 > top of Java-index,Core,Core APIs...
# 11

> Hello. If you don't mind can you plz give little more

> information about y3k problem? please.

also known as Y2K++

jwentinga at 2007-7-28 17:51:32 > top of Java-index,Core,Core APIs...
# 12

Guess it's just a --Y4K problem like...

ibanna at 2007-7-28 17:51:32 > top of Java-index,Core,Core APIs...
# 13

"Hello. If you don't mind can you plz give little more

information about y3k problem? please."

Its like Y2K, but it happens like, 1000 years after it. I think it has something to do with the return of Satan (or is it Elvis) to earth or something like that.

George123a at 2007-7-28 17:51:32 > top of Java-index,Core,Core APIs...