Comparing time in java between epoch milliseconds and LocalDateTime

Question

I have a timestamp in epoch milliseconds and I want to check if it is between two LocalDateTime stamps. What's the best way to do this in java?

Answer 1

One way to do it is to convert the milliseconds to LocalDateTime

LocalDateTime date = Instant.ofEpochMilli(milliseconds)
        .atZone(ZoneId.systemDefault())
        .toLocalDateTime();
LocalDateTime start = LocalDateTime.now().minusMinutes(1);
LocalDateTime end = LocalDateTime.now().plusMinutes(1);

if (date.isAfter(start) && date.isBefore(end)) {
  // date is between start and end
}

Answer 2

tl;dr

You cannot compare a LocalDateTime to a moment until assigning a time zone (or offset-from-UTC).

org.threeten.extra.Interval                     // Represents a span-of-time attached to the timeline, as a pair of `Instant` objects, a pair of moments in UTC.
.of ( 

    myLocalDateTimeStart
    .atZone( ZoneId.of( "Pacific/Auckland" ) )  // Determine a moment by assigning an time zone to a `LocalDateTime` to produce a `ZonedDateTime`, from which we extract an `Instant` to adjust into UTC.
    .toInstant() ,

    myLocalDateTimeStop
    .atZone( ZoneId.of( "Pacific/Auckland" ) )  // Returns a `ZonedDateTime` object.
    .toInstant()                                // From the `ZonedDateTime`, extract a `Instant` object.

)                                               // Returns `Interval` object.
.contains(        
    Instant.ofEpochMilli( 1_532_463_173_752L )  // Parse a count of milliseconds since 1970-01-01T00:00:00Z as a moment in UTC, a `Instant` object.
)                                               // Returns a boolean.             

Details

Comparing time in java between epoch milliseconds and LocalDateTime

You cannot. That comparison is illogical.

A LocalDateTime does not represent a moment, is not a point on the timeline. A LocalDateTime represents potential moments along a range of about 26-27 hours, the range of time zones around the world.

As such it has no real meaning until you place it in the context of a time zone. If that particular date and time were invalid in that zone, such as during a Daylight Saving Time (DST) cut-over, or during some other such anomaly, the ZonedDateTime class adjusts.

ZoneId z = ZoneId.of( "Africa/Tunis" ) ; 
ZonedDateTime zdt = myLocalDateTime.atZone( z ) ;

For comparisons, we will adjust into UTC by extracting an Instant object from your start and stop ZonedDateTime objects.

Instant start = zdtStart.toInstant() ;
Instant stop = zdtStop.toInstant() ;

Now parse your count of milliseconds since the epoch reference of first moment of 1970 as a Instant. Instant has an even finer resolution, nanoseconds.

Instant instant = Instant.ofEpochMilli( 1_532_463_173_752L ) ;

Compare to see if your epoch-milliseconds represent a moment in between our stop and start Instant objects. Usually in date-time work, the Half-Open approach is best, where the beginning is inclusive while the ending is exclusive.

Tip: A shorter way of saying “is equal to or is after” is to say “is not before”.

boolean inRange = ( ! instant.isBefore( start ) ) && instant.isBefore( stop ) ;

To make this work easier, add the ThreeTen-Extra library to your project. Use the Interval class.

Interval interval = Interval.of( start , stop ) ;
boolean inRange = interval.contains( instant ) ;  // Uses Half-Open approach to comparisons.

---

Tip: If you had intended to be tracking moments, you should not have been using LocalDateTime class at all. Instead, use the Instant, OffsetDateTime, and ZonedDateTime classes.

---

About java.time

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.

You may exchange java.time objects directly with your database. Use a JDBC driver compliant with JDBC 4.2 or later. No need for strings, no need for java.sql.* classes.

Where to obtain the java.time classes?

• Java SE 8, Java SE 9, Java SE 10, and later
  • Built-in.
  • Part of the standard Java API with a bundled implementation.
  • Java 9 adds some minor features and fixes.
• Java SE 6 and Java SE 7
  • Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
• Android
  • Later versions of Android bundle implementations of the java.time classes.
  • For earlier Android (<26), the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….

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.

Answer 3

When comparing an Instant (time-since-Epoch) with a LocalDateTime, you always need to consider the timezone of the local times. Here's an example:

Instant now = Instant.now();

LocalDateTime start = LocalDateTime.of(2018, 7, 24, 0, 0);
LocalDateTime end = LocalDateTime.of(2018, 7, 24, 23, 59);

final ZoneId myLocalZone = ZoneId.of("Europe/Paris");

if (now.isAfter(start.atZone(myLocalZone).toInstant()) 
        && now.isBefore(end.atZone(myLocalZone).toInstant())) {

    // the instant is between the local date-times

}