Why java 8 has now method in LocalDateTime class

Question

As we aware that, in java we can use existing API's to get the current date and time, compare to that what is the difference between the new LocalDateTime class now() method.

Answer 1

tl;dr

• If referring to Date, Calendar, and SimpleDateFormat, those are terrible old classes, now legacy. Never use.
• Use only the modern java.time classes.
• LocalDateTime cannot represent a moment, as it purposely lacks any concept of time zone or offset-from-UTC. So LocalDateTime.now is of no practical use.
• Capture the current moment using Instant.now for UTC, or ZonedDateTime.now for a particular time zone.

Avoid legacy date-time classes

If by “existing API's” you meant the old date-time classes such as Date, Calendar, and SimpleDateFormat, you should avoid those. While they were well-intentioned industry-leading attempts at date-time handling, they proved to be poorly designed, confusing, and troublesome. They are now legacy.

Use java.time

Instead, use the java.time classes. Added to Java 8 and later. Much of the functionality was back-ported to Java 6 & 7 & Android as well.

Local… types

The “Local…” classes lack any concept of offset-from-UTC or time zone. As such, they are only a vague idea about possible moments. Without an offset or zone the have no real meaning.

An example of a local date-time is when Christmas begins, 2016-12-25T00:00:00. That does not determine a specific point on the timeline until we apply an offset or zone. Christmas starts earlier in the east. That is why Santa starts his deliveries in the Pacific such as midnight in Auckland NZ and works his way towards Asia with its later midnight, then flies the reindeer on to India after its midnight begins later, and so on westwards.

LocalDateTime not often used

So while there might be use-cases for calling now on LocalDateTime, I cannot imagine one.

The main use for LocalDateTime is in parsing strings that lack any indication of offset or zone. Such strings are poorly designed as they are incomplete. Would you communicate a price without specifying the currency? So too it is unwise to specify a date and a time but no offset/zone. At any rate, when you do have such strings lacking offset/zone, parse with LocalDateTime.

LocalDateTime ldt = LocalDateTime.parse( "2016-01-23T12:34:56.789" );

If you know the intended offset because of your given scenario, apply it.

ZoneOffset offset = ZoneOffset.ofHours( -7 );
OffsetDateTime odt = ldt.atOffset( offset );  // Now we have a moment, a specific point on the timeline.

Better yet, if you know the time zone because of your given scenario use that instead of an offset. A zone is an offset plus the set of rules for handling anomalies such as Daylight Saving Time (DST).

ZoneId zone = ZoneId.of( "America/Montreal" );
ZonedDateTime zdt = ldt.atZone( zone );  // Now we have a moment, a specific point on the timeline.

In common business apps we tend to care about precise moments: When did the invoice arrive, When does the contract expire, Appointment start time, and such. For such point-on-the-timeline values, we use Instant, OffsetDateTime, and ZonedDateTime. Search Stack Overflow for many examples and more discussion. Each of these offer a now method. Calling their now method retains the important offset/zone info while capturing the current moment. In contrast, calling LocalDateTime.now discards that offset/zone info intentionally, rarely what you want.

Tip: Always pass the optional offset or zone argument to now.
If omitted you are relying implicitly on the JVM’s current default time zone being applied. This default can be changed at any moment during runtime by any code on any app within that JVM. Better to specify explicitly your desired/expected offset or zone. IMHO, that optional argument should have been required to remind programmers that they must be always be consciously aware of time zone.

Current moment

Capture the current moment in UTC using Instant.

May be captured in a resolution as fine as nanoseconds but more likely microseconds or milliseconds depending on limitations of your JVM implementation, your host hardware clock, and your host OS.

Instant instant = Instant.now() ;  // Capture current moment in UTC.

Adjust from UTC to the wall-clock time used by the people of a particular region (a time zone).

ZoneId z = ZoneId.of( "Africa/Casablanca" ) ;
ZonedDateTime zdt = instant.atZone( z ) ;

Or, as a shortcut, skip the Instant part.

ZonedDateTime zdt = ZonedDateTime.now( z ) ;

If the zone argument is omitted, the JVM’s current default time zone is applied implicitly. Better to specify your desired/expected 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.

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, Java SE 11, and later - 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.