Comparing current time with a time of data enty in database

Question

I have a database in which I have users with their info etc. One field is named "maeindat" and there is stored the date of the entry (creation) of that entitiy ( user )

Now I want to compare if current time is "smaller" than input date and if it is set current date into the field, but if date of entry is bigger than current date set date of entry into the field

current date < date of entry --> set current date into the field

current date > date of entry --> set date of entry in field

Bellow is the code I'm trying out...

String maeindat = rs.getString("MAEINDAT");

LocalDateTime currTime = LocalDateTime.now();

if(currTime.isBefore(maeindat)) {
    currTime = maeindat;
}
else if(currTime.isAfter(maeindat)) {
    maeindat = maeindat;
}

UPDATE:

String maeindat = rs.getString("MAEINDAT");

DateTimeFormatter formatter = DateTimeFormatter.ofPattern("YYYYMMDDHH24MI");
LocalDateTime maeindatDate = LocalDateTime.parse(maeindat, formatter);

LocalDateTime currTime = LocalDateTime.now();

if(currTime.isBefore(maeindatDate)) {
    currTime = maeindatDate;
}
else if (currTime.isAfter(maeindatDate)) {
    maeindatDate = maeindatDate;
}

Answer 1

tl;dr

Comparing a LocalDateTime with current moment makes no sense logically.

myResultSet.getObject(
    … ,
    Instant.class            // Retrieve from database column of type similar to SQL-standard `TIMESTAMP WITH TIME ZONE`.
).isBefore( Instant.now() )  // Or `isAfter` or `equals` or combine with `!` (meaning NOT before/after).

Apples & Oranges

You cannot compare strings to date-time objects. Parse your strings into date-time objects, and then you may compare.

LocalDateTime

The LocalDateTime class lacks any concept of time zone or offset-from-UTC. Use this class only if using a column in your database of a type similar to SQL-standard TIMESTAMP WITHOUT TIME ZONE.

This type is not intended to represent actual moments, specific points on the timeline. Instead this type is only a rough idea of potential moments spread over a range of about 26-27 hours.

If we say "Santa delivers the toys just after midnight on December 25th", do we mean just after midnight in Auckland, New Zealand or do we mean midnight in Kolkata India which occurs hours later? Or Paris France even more hours later? "Midnight" has no real meaning until you specify Auckland, Kolkata, or Paris.

Comparing a LocalDateTime to the current moment makes no sense! The LocalDateTime has no real meaning without the context of a time zone or offset. If you know for certain of an appropriate time zone for that value, apply a ZoneId to get a ZonedDateTime. At that point, you have an actual moment, a point on the timeline.

ZoneId z = ZoneId.of( "Asia/Kolkata" ) ;
ZonedDateTime zdt = myLocalDateTime.atZone( z ) ;  // Converting vague idea about potential moments into an actual moment, a specific point on the timeline.

Instant

If you intend to represent actual moments, use SQL-standard type TIMESTAMP WITH TIME ZONE and Java type Instant (UTC) or possibly ZonedDateTime.

The Instant class represents a moment on the timeline in UTC with a resolution of nanoseconds (up to nine (9) digits of a decimal fraction).

Instant instant = myResultSet.getObject( … , Instant.class ) ;

Capture the current moment in UTC.

Instant instantNow = Instant.now() ;  // Current moment in UTC.

Compare using isBefore, isAfter, equals.

boolean targetPassed = instant.isAfter( instantNow ) ; 

Smart objects, not dumb strings.

With a JDBC driver complying with JDBC 4.2 and later, you may directly exchange java.time objects with your database. No need for converting to/from strings.

LocalDateTime ldt = myResultSet.getObject( … , LocalDateTime.class ) ; // For database column of type like `TIMESTAMP WITHOUT TIME ZONE`.

Or…

Instant instant = myResultSet.getObject( … , Instant.class ) ; // For database column of type like `TIMESTAMP WITH TIME ZONE`.

---

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.

Where to obtain the java.time classes?

• Java SE 8, Java SE 9, 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, 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.