Minimum / maximum date / time in JodaTime

Question

Is there a way in JodaTime to build a Date / DateTime that will always be less / more than any other Date / DateTime? Something along the lines

DateTime bigBang = DateTime.xxx(); DateTime endOfUniverse = DateTime.yyy(); 

Limitation: I do not want to use the standard Java Date libraries.

Answer 1

java.time

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

Min / max in java.time, see my answer to a similar question.

Joda time

Joda-Time tracks time in milliseconds since the first moment of 1970 in UTC . This counter is maintained using a 64-bit long integer. Thus, technically, the maximum and minimum are the +/- limits of long .

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

Joda-Time does not have such minimum / maximum values ​​that could be used as constants. In contrast, note that the Joda-Times successor, java.time, built into Java 8 and later, does offer the constants LocalDateTime.MIN and LocalDateTime.MAX .

By the way, the Joda-Time team advised us to switch to java.time. Most of the java.time functionality is ported to Java 6 and 7 in ThreeTen-Backport , and then adapted for Android in ThreeTen-ABP .

Too big, too small

Beware of these extremes. Their use is not practical. Different libraries, applications, databases, and other receivers / sources of date and time values ​​can have very different restrictions, some much more, but usually much less.

For example, many systems use the old UNIX & POSIX time-tracking tradition as a 32-bit integer for integer seconds from 1970-01-01T00: 00: 00Z. A natural +/- limit of two billion seconds leads to an impending 2038 problem .

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

Temporary solution

You can define your own minimum / maximum.

You may need 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 displaying on the screen and in reports. Visually, four nines stand out as a dummy date.

Or you may need the expected minimum value that matches your business logic. If you are creating a new billing system, then you know that a year should always be this year or later.

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

 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 invoking these 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 

Answer 2

When all dates are within the same TimeZone, you can create a DateTime object with fields assigned to the minimum or maximum 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 the following exception:

Thus, using the maximum number of years from exclusion, I came up with the following end date for the date:

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

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

Answer 3

After reading many different touches on this, I finally decided to find out the minimum case, which works at least, and the maximum for the UTC time zone. And it turns out that trying to use Long MIN_VALUE and MAX_VALUE send me rabbit footprints.

So, given the following code snippet:

 new DateTime(milliseconds, DateTimeZone.UTC) 

here are the minimum / maximum values ​​that work for milliseconds (tested on Java 1.7):

 UTC_DATE_TIME_MIN_VALUE_IN_MILLIS = 9223372017129599999L UTC_DATE_TIME_MAX_VALUE_IN_MILLIS = -9223372017043200000L 

Both of these values ​​are approximately 20 billion from Long.MIN_VALUE and Long.MAX_Value .