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..
# 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 >

# 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
# 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 >

# 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
# 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.
# 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 >

# 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 :)
# 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.
# 9
Hello. If you don't mind can you plz give little more information about y3k problem? please.
# 10
!!!
ejpa at 2007-7-28 17:51:32 >

# 11
> Hello. If you don't mind can you plz give little more
> information about y3k problem? please.
also known as Y2K++
# 12
Guess it's just a --Y4K problem like...
ibanna at 2007-7-28 17:51:32 >

# 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.