16

Year 2038 Bug is all over the web, But this seems to be a unix issue. How will this affect java Date ?

Sean Patrick Floyd
  • 292,901
  • 67
  • 465
  • 588
sasivi
  • 169
  • 1
  • 3
  • 7
    Will there be another Roland Emmerich movie about that one? – Sean Patrick Floyd Nov 30 '10 at 12:28
  • It's not a bug. Everyone knows the world will end by 2038. The only question is how. My guess is zombie plague. –  Nov 30 '10 at 12:30
  • 2
    Should not bother anyone .. as we all know, earth ends in 2012 anyways. Write some cool stuff instead – chzbrgla Nov 30 '10 at 12:32
  • 1
    @chzbrgla - no no - there will be survivors in the 2012 thing. But they won't last long... –  Nov 30 '10 at 12:34
  • 12
    Why should I worry about it now, when I can get paid 10k a day to fix it in 2037? – skaffman Nov 30 '10 at 12:34
  • 7
    @skaffmann in 2037, 10k will probably get you a hamburger and fries :-) – Stephen C Nov 30 '10 at 13:25
  • @ S.P.Floyd - seanizer, that would be in 3D... lol.. – Rajan Nov 30 '10 at 13:48
  • @sasivi: It is not a Un*x issue. It is a "32-bit Un*x" issue and even not all 32-bits Un*x are affected (only the one counting milliseconds since the epoch using 32 bits are affected and, shocking revelation, it is possible to count on 64 bits even on 32 bits CPUs!). If you think there will be a lot of 32 bits Un*x (still counting time on 32 bits) around by 2038 I suggest a visit to the closest mental hospital ; ) – SyntaxT3rr0r Nov 30 '10 at 14:19
  • @ all: it is really scary to see all these comments and answers stating: *"all OSes will be 64 bits by then"* as if counting on 64 bits wasn't possible on a 32 bits OS. Mindboggling. – SyntaxT3rr0r Nov 30 '10 at 14:21
  • @Webinator, actually, your comment is inaccurate. `time_t` is required to count seconds, not milliseconds. – Matthew Flaschen Nov 30 '10 at 14:26
  • 2
    You still want to use Java in 2038? That would be lame ... – Martin Nov 30 '10 at 14:48

5 Answers5

31

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.

Matthew Flaschen
  • 278,309
  • 50
  • 514
  • 539
  • 2
    +1 - but surely Java on Unix sometimes needs to talk dates with the underlying O/S. Unlikely a real issue (until 2038), but maybe worth a mention. –  Nov 30 '10 at 12:32
  • 1
    @Steve, true, but I think the question is specifically about `java.util.Date`, not anything involving `time_t`. – Matthew Flaschen Nov 30 '10 at 12:38
  • How does a Java app get it's time in the first place? Java might be able to handle dates well but GIGO might still be a problem. – BCS Nov 30 '10 at 22:36
  • @BCS - yes, but the current date won't be 2038 until 2038. So for now, what's the problem? Likewise for e.g. file dates - unless you're sharing files with a time-traveller. So - unlikely a real issue until 2038. –  Dec 01 '10 at 06:19
  • @Steve314: I was (and am) agreeing with you. – BCS Dec 01 '10 at 14:58
  • 1
    @BCS - but you assume I agree with myself? I play devils advocate a lot. Mind you, the trouble with playing devils advocate is... –  Dec 02 '10 at 07:17
5

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.

John
  • 1,635
  • 15
  • 22
4

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.

JOTN
  • 6,120
  • 2
  • 26
  • 31
  • That haven't been patched to fix this. I imagine some embedded systems might still use 32-bit. – Peter Lawrey Nov 30 '10 at 12:38
  • 1
    I'm quite sure that 28 years from now not even embedded systems would use 32-bit – Goran Jovic Nov 30 '10 at 12:44
  • 2
    @Goran - washing machines may still use 8 bit, just as they probably do now. Not sure that clothes or dirt are going to change much in the next 28 years. But if something *does* change (digital rights management to prevent you using unauthorised detergents, maybe?) then a 32 bit Unix box may be needed. –  Dec 01 '10 at 06:24
0

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.

user2213307
  • 111
  • 1
  • 1
  • 4
-1

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.

aksarben
  • 588
  • 3
  • 7
  • The answers above show that this is a much subtler problem than that, and Java is exposed to it, since it is not perfectly insulated from the underlying O/S for many common paths. – Derek T. Jones Jan 30 '20 at 02:09