Min/Max Date/DateTime in JodaTime

When all dates are within the same TimeZone, you can create DateTime object with fields assigned to minimum or max value.
However when using this constructor

DateTime(int year, int monthOfYear, int dayOfMonth, int hourOfDay, int minuteOfHour, int secondOfMinute)

with Years.MAX_VALUE.getYears() I have below exception:

So using the max number of years from exception, I have came up with the following end-of-universe dateTime:

DateTime dtMax = new DateTime(292278993, 12, 31, 23, 59, 59);
System.out.println(dtMax);
// prints 292278993-12-31T23:59:59

See documentation for more details.
Also an interesting discussion can be read here.

java.time

The Joda-Time project is now in maintenance mode. The team advises migration to the java.time classes.

For min/max in java.time, see my Answer on a similar Question.

Joda-Time

Joda-Time tracks time as a count of milliseconds since the epoch of first moment of 1970 in UTC. This count is kept using a 64-bit long integer. So, technically, the maximum and minimums are the +/- limits of a long.

… new DateTime( Long.MIN_VALUE )
… new DateTime( Long.MAX_VALUE )

Joda-Time has no such minimum/maximum values available conveniently as constants. In contrast, note that Joda-Time’s successor, java.time built into Java 8 and later, does indeed offer the constants LocalDateTime.MIN and LocalDateTime.MAX.

By the way, the Joda-Time team has advised we should migrate to java.time. Much of the java.time functionality is back-ported to Java 6 & 7 in the ThreeTen-Backport, further adapted to Android in ThreeTen-ABP.

Too big, too small

Beware of these extremes. Their use is not practical. Various libraries, apps, databases, and other sinks/sources of date-time values may have much different limits, some much larger but typically much smaller.

For example, many systems use the old tradition from UNIX & POSIX of tracking time as a 32-bit integer count of whole seconds since 1970-01-01T00:00:00Z. The natural limit of +/- two billion seconds results in the looming Year 2038 Problem.

Another limit is the physical display size of fields on forms and reports that expect only four digits in a year number.

Workaround

You can define your own min/max.

You may want extreme values such as year 0000 and year 9999. Joda-Time supports years later than 9,999 but I would stick with 4 digits to fit the commonly used formats for display on-screen and in reports. Visually, the four nines stand out as a bogus date.

Or you may want an expected minimum value appropriate to your business logic. If building a new invoicing system, then you know the year should always be this year or later.

I suggest defining constants on a helper class. Something like this:

package com.example;

import org.joda.time.DateTime;
import org.joda.time.DateTimeZone;

public class JodaTimeHelper {

    static final public DateTime START_OF_TIME = new DateTime( 0000, 1, 1, 0, 0, 0, DateTimeZone.UTC );
    static final public DateTime END_OF_TIME = new DateTime( 9999, 1, 1, 0, 0, 0, DateTimeZone.UTC );

    static final public DateTime MINIMUM_INVOICE_DATETIME = new DateTime( 2015, 1, 1, 0, 0, 0, DateTimeZone.UTC );

}

Here is the syntax for calling those constants.

System.out.println( "START_OF_TIME: " + JodaTimeHelper.START_OF_TIME );
System.out.println( "END_OF_TIME: " + JodaTimeHelper.END_OF_TIME );
System.out.println( "MINIMUM_INVOICE_DATETIME: " + JodaTimeHelper. MINIMUM_INVOICE_DATETIME );

When run.

START_OF_TIME: 0000-01-01T00:00:00.000Z
END_OF_TIME: 9999-01-01T00:00:00.000Z
MINIMUM_INVOICE_DATETIME: 2015-01-01T00:00:00.000Z