Unix Y2038 Bug

19 September 2009 ~ blog java

Apparently there are still some short-sighted developer date-based issues out there, one of which is the
Year 2038 Problem, which is a unix-based problem with how the milliseconds since 1970 value is stored... it's a 32-bit value which will wrap around into negative numbers in 2038.

I ran a quick sanity check in Linux:

Date expiration = new Date(Long.MAX_VALUE);

and found that a Mac and Linux running Sun's JVM seems to be fine:

Sun Aug 17 01:12:55 CST 292278994

while GCJ on Linux produced:

Exception in thread "main" java.lang.IllegalArgumentException: month out of range:-19461555
at gnu.java.util.ZoneInfo.getOffset(int, int, int, int, int, int) (/usr/lib/libgcj.so.5.0.0)
at java.util.GregorianCalendar.computeFields() (/usr/lib/libgcj.so.5.0.0)
at java.util.Calendar.setTimeInMillis(long) (/usr/lib/libgcj.so.5.0.0)
at java.util.Date.toString() (/usr/lib/libgcj.so.5.0.0)
at java.io.PrintStream.println(java.lang.Object) (/usr/lib/libgcj.so.5.0.0)
at Main.main(java.lang.String[]) (Unknown Source)

Ouch! This is kind of a subtle issue since your JVM may be giving you the correct value; however, your database which may
be running on Linux might give you the wrong value from a time-based operation (or an error). This is one to keep an eye one.

Creative Commons License CoffeaElectronica.com content is copyright © 2016 Christopher J. Stehno and available under a Creative Commons Attribution-ShareAlike 4.0 International License.