I'm writing a bit of logic that requires treating null dates as meaning forever in the future (the date in question is an expiration date, which may or may not exist). Instead of putting in special cases for a null date throughout the code, I want to just convert null into the maximum possible Date. I don't see any obvious ways to get such a value without hard coding it. What's the best way to get the maximum value of whatever Date implementation is being used?
-
2For Joda-Time, see [this similar Question](http://stackoverflow.com/q/32593206/642706). – Basil Bourque Sep 15 '15 at 21:03
-
1There is no good answer to this because (a) the maximum values and (b) the granularity of date-time values vary amongst programming languages, libraries, databases, and so on. I suggest arbitrarily choosing a hard-coded value far enough out to be sure it outlives your app but not so far out as to go beyond the limits of any component. Something like `2666-01-01T00:00:00.0Z`. – Basil Bourque Apr 10 '16 at 04:50
9 Answers
Try
new Date(Long.MAX_VALUE)
which should give you the longest possible date value in Java.

- 28,143
- 8
- 66
- 82

- 13,468
- 4
- 44
- 56
-
9Just to play devil's advocate here... that solution still makes an assumption about the Date object's implementation. What if my code is compiled in java version 9 sometime in the far future, Date is upgraded to be able to represent the year quattuordecillion, but the constructor which takes a long is limited to the original 64 bit date range... – jthg Nov 16 '09 at 18:57
-
38lol... well, in that case at least the Date value is so far in the future that either way it should still be considered unreachable. "Sun Aug 17 00:12:55 MST 292278994" under the current Java 6 impl. I will be impressed if your code is still around in 292278994. :-) – cjstehno Nov 16 '09 at 19:05
-
1I do agree with one of the other answers, that this code should be wrapped in another helper class of some sort, rather than just used outright. – cjstehno Nov 16 '09 at 19:07
-
3
-
1jthg: It won't be, Sun likes to keep JDK API backwards compatible and they're working on new Date/Time API(JSR-310) anyways which is based on joda-time. – Esko Nov 16 '09 at 20:33
-
To add @jhg's point, another assumption one could make with this solution is if one was doing date comparisons. (Of course, this could only happen if a max date was persisted outside the JVM process.) That said, the JVM spec would have to change for Long.MAX_VALUE to change, and I really doubt this would ever happen. – three-cups Jan 28 '14 at 21:36
Encapsulate the functionality you want in your own class, using Long.MAX_VALUE will most likely cause you problems.
class ExpirationDate {
Date expires;
boolean hasExpiration() {
return expires == null;
}
Date getExpirationDate() {
return expires;
}
boolean hasExpired(Date date) {
if (expires == null) {
return true;
} else {
return date.before(expires);
}
}
...
}

- 43,583
- 4
- 41
- 61
-
+1; this will lead to much more readable checking for expiration in the future. – Rob Nov 16 '09 at 18:52
-
The logic I need only applies to code within a single method, so I think this is unnecessary. – jthg Nov 18 '09 at 16:06
-
1I would do it the other way around. In my mind, expires==null means there is NO expiration time, so any date would be legal. – DGoiko Sep 11 '19 at 16:19
+1 to the Long.MAX_VALUE suggestions. It seems that this would help you if you sort stuff by your date field.
However, instead of constructing a date from some the large constant value where ever you need the date, use a globally visible singleton to hold a Date instance that represents your special value:
class DateUtil
{
public static final Date NO_EXPIRE = new Date( Long.MAX_VALUE );
}
Then you can use simple identity comparison (mydate == DateUtils.NO_EXPIRE) to test if a particular date is of your special case instead of obj.equals(); (ie. mydate.equals ( DateUtils.NO_EXPIRE ); )

- 1,744
- 1
- 14
- 20
-
1this still won't give you the MAXIMUM date value unless you include the UTC TimeZone! – Nov 22 '09 at 02:50
-
4@JarrodRoberson Incorrect, the time zone is irrelevant. A **java.util.Date is always in UTC**. This answer correctly determines the last moment of time that can be represented by a java.util.Date object. Is there some other aspect to your comment that I'm misunderstanding? – Basil Bourque Oct 30 '14 at 05:47
Here is what I do:
public static final TimeZone UTC;
// 0001.01.01 12:00:00 AM +0000
public static final Date BEGINNING_OF_TIME;
// new Date(Long.MAX_VALUE) in UTC time zone
public static final Date END_OF_TIME;
static
{
UTC = TimeZone.getTimeZone("UTC");
final Calendar c = new GregorianCalendar(UTC);
c.set(1, 0, 1, 0, 0, 0);
c.set(Calendar.MILLISECOND, 0);
BEGINNING_OF_TIME = c.getTime();
c.setTime(new Date(Long.MAX_VALUE));
END_OF_TIME = c.getTime();
}
Note that if the TimeZone is NOT UTC you will get offsets from the "end of time", which won't be maximal values. These are especially useful for inserting into Database fields and not having to have NULL dates.
-
Would this really matter if all of the dates I'm working with is in the same time zone? 'new Date(Long.MAX_VALUE)' would get the maximum date for the current time zone. – jthg Nov 17 '09 at 19:07
-
have you considered adopting the use of Joda Time?
It's slated to be included in java 7 as the basis for JSR-310
The feature that may interest you is ZeroIsMaxDateTimeField which basically swaps zero fields for the maximum value for that field within the date-time.

- 8,456
- 3
- 35
- 50
One problem I see is that for sorting on expiration date, using a null isn't easily sortable. So replacing with an actual value (even if it's an arbitrary sentry value well into the future) may be needed.
I suppose another way of treating "no expiration" is simply to say something expires 100 years in the future... Unless your database is dealing with long-term contracts!

- 11,153
- 5
- 28
- 33
I like Instant.MAX because it is more likely to be supported in the future than Long.MAX_VALUE.
Note that as of today, though, Instant.MAX.toEpochMilli() throws an overflow error.

- 15,239
- 27
- 91
- 157