I am trying to compare two dates in this format.
date1 = Wed Jul 13 17:23:33 GMT+02:00 2016
date2 = Wed Jul 13 17:23:31 CEST 2016
if(date1.after(date2){
//my logic
}else if(date1.before(date2){
//my logic
}
The comparison seems to have happened only a few times, where it is thought to be wrong?
ZonedDateTime.parse(
"Wed Jul 13 17:23:33 GMT+02:00 2016" ,
DateTimeFormatter.ofPattern( "EEE MMM d HH:mm:ss z uuuu" )
.withLocale( Locale.ENGLISH )
)
.isAfter(
ZonedDateTime.parse(
"Wed Jul 13 17:23:31 CEST 2016" ,
DateTimeFormatter.ofPattern( "EEE MMM d HH:mm:ss z uuuu" )
.withLocale( Locale.ENGLISH )
)
)
The modern approach uses the java.time classes.
String inputX = "Wed Jul 13 17:23:33 GMT+02:00 2016";
String inputY = "Wed Jul 13 17:23:31 CEST 2016";
Define a formatting pattern to match your input strings.
DateTimeFormatter f = DateTimeFormatter.ofPattern( "EEE MMM d HH:mm:ss z uuuu" ).withLocale( Locale.ENGLISH );
The ZonedDateTime class represents a moment, a point on the timeline, with a wall-clock time used by the people of a particular region (a time zone). Specify a Locale to determine (a) the human language for translation of name of day, name of month, and such, and (b) the cultural norms deciding issues of abbreviation, capitalization, punctuation, separators, and such.
ZonedDateTime x = ZonedDateTime.parse( inputX , f );
ZonedDateTime y = ZonedDateTime.parse( inputY , f );
x.toString(): 2016-07-13T17:23:33+02:00[GMT+02:00]
y.toString(): 2016-07-13T17:23:31+02:00[Europe/Paris]
In real work, trap for the exception thrown when encountering faulty input.
Compare using isBefore, isAfter, isEqual, or methods. Be aware that the Comparable::equals method implementation differs in behavior (read the doc).
if( x.isBefore( y ) ) { // BEFORE
…
} else if( x.isAfter( y ) ) { // AFTER
…
} else if( x.isEqual( y ) ) { // EQUAL
…
} else { // UNREACHABLE
… // Handle error condition. Should be unreachable.
}
By the way, your two inputs use a very poor choice of formats. The first has only an offset-from-UTC rather than an actual time zone. The second carries a pseudo-zone of "CEST". Such 3-4 letter labels are common in mainstream media, but are not true time zones, are not standardized, and are not even unique(!).
Specify a proper time zone name in the format of continent/region, such as America/Montreal, Africa/Casablanca, or Pacific/Auckland. Never use the 3-4 letter abbreviation such as EST or IST as they are not true time zones, not standardized, and not even unique(!).
ZoneId z = ZoneId.of( "America/Montreal" ) ;
Whenever possible, use standard ISO 8601 formats when exchanging date-time values as text. The java.time classes use standard formats by default when parsing/generating strings. The ZonedDateTime class wisely extends the standard format by appending the name of the time zone in square brackets, as seen above in our example.
The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date, Calendar, & SimpleDateFormat.
The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.
Using a JDBC driver compliant with JDBC 4.2 or later, you may exchange java.time objects directly with your database. No need for strings nor java.sql.* classes.
Where to obtain the java.time classes?
The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval, YearWeek, YearQuarter, and more.
Use compareTo method.
int compare = date1.compareTo(date2);
compare > 0, if date1 is greater than date2
compare = 0, if date1 is equal to date2
compare < 0, if date1 is smaller than date2
