Java8: LocalDateTime or TimeStamp

Question

Which is preferred when or where?

I do not know exactly what the actual differences between the two are.

From the LocalDateTime documentation

... Time is represented by nanosecond accuracy. For example, the value "October 2, 2007 at 13: 45.30.123456789" might be stored in LocalDateTime.

I suggested that LocalDateTime can also take up to nanoseconds. So that I can replace my codes with LocalDateTime , they are declared as TimeStamp . Please correct me if I am wrong.

Scenario: We planned to upgrade our project using Java-8. Modified styles of old codes with new JAVA-8 functions (for example: Lambda, Streams, etc .;). But we had trouble deciding on the Dates and Times. Most of the codes from java.util.Date have been changed to java.time.LocalDate or java.time.LocalDateTime . For TimeStamp cases , I have no idea about the question

Should we replace them with LocalDateTime ?

Answer 1

In current development, you should prefer LocalDateTime and other Java8 time classes.

• They provide the advantage of a clearer separation between point-in-time ( Instant ) and duration ( Duration ) or fragment-based definitions ( LocalDate , LocalTime ).

• They allow a really good set of methods for manipulation / computation logic (unlike java.util.Date ).

• Unit conversion ( Duration.toDays() ) is also included.

• Last but not least, the hellish realm of Timezone ( ZonedDateTime ).

A minor flaw is the lack of support for quite a few third-party APIs, which you might want to use. But this should just be a matter of time and the conversion from the Java8 time API to Calendar / Date is not showstopper.

If you have a mature program, then replacing older Java8 date / calendar based interfaces is just a risk until you take advantage of some of the benefits mentioned above.

If you want to replace the old TimeStamp parameter TimeStamp something from the Java8 time toolkit, you can use Instant , LocalDateTime or ZonedDateTime . The difference is that the Instant value is treated as ZoneOffset.UTC when it comes to the calculation, while LocalDateTime by definition not related to the time zone.

Hint: using LocalDateTime is a pretty nice thing if something should happen in 2018-01-02 10:24:12 for the system, for example. India and systems in the USA. In almost all other cases, you can explicitly specify the time zone using Instant or ZonedDateTime .

Answer 2

Both java.util.Date and and java.sql.Timestamp are actually equivalents to java.time.Instant , not LocalDateTime , Date Timestamp and Instant are Unix time instances, and LocalDateTime is DateTime in the current time zone.

You can clearly see that, since both classes have this good method (inherited from java.util.Date ):

 java.util.Date::toInstant 

I assume that you meant by replacing Date with LocalDate , you actually replaced java.sql.Date , not java.util.Date . Now sql.Date is equivalent to LocalDate and not equivalent to Instant, because sql.Date is missing the Time component (although sql.Date is a subclass of util.Date, calling getSeconds() on it will throw an exception).