Difference between java.util.Date and java.time.LocalDate in java [closed]

Question

I want to know the difference between java.util.Date and java.time.LocalDate.

I've heard that java.time.LocalDate brings user environment time, not server time, but I want to know if it's true.

In other words, if a user manipulates his or her system time, I want to know if it counts as changed time, not server time.

Iscariot

How to Ask What have you tried to find your answer? Why didn't the results help you? Did you try google? Did you try searching stackoverflow? – Obscuration

"brings user environment time" - What is that? "not server time" - What is that? – Gratification

java.time.LocalDate is the date the calendar on the wall says. java.util.Date is not a date, it's an instant, and actually represents a millisecond offset from Unix epoch. – Broken

both of them are not aware about server or client (at most about the time of the machine they are running on, if using the corresponding constructor or method that uses such time) – Blacksmith

Everything is different between those two except they both have Date in the name and both have something to do with date and/or time. For starters, a Date is a point in time, while LocalDate is a date. Date is poorly designed and long outdated, while LocalDate is modern and recommended for dates. – Midsummer

Does this answer your question? Java 8 Date API vs Calendar / Date / DateFormat – Armandinaarmando

tl;dr… Use one. Avoid the other. – Odontalgia

This is a perfectly legitimate question with helpful answers. I don't know why people are flaming it. – Planar

Answer 1

Avoid java.util.Date

The main difference is: For new code you should use LocalDate to represent a calendar date, not java.util.Date. Date is poorly designed and long outdated, there is absolutely no reason why you should want to use it.

User environment time versus server time

LocalDate gives you the date that you set it to (whereas setting a Date to a specific date is non-trivial but possible too). What you get from trying to set LocalDate (or Date) to “today” or “now” depends on a couple of things:

• The clock from which you obtain the time, again depending on your setup/architecture
• The time zone

Both Localdate.now(desriedTimeZone) and new Date() will obtain the time from the computer they are running on. So if you have got a Java client running on the user’s computer and the user tampers with the clock on that computer, they may both give you a false time.

On the other hand, if the client has got a connection to a server that you control, it shouldn’t be hard to obtain the current date and time from that server (except for the delay incurred, probably much less than a second).

Midsummer

"On the other hand, if the client has got a connection to a server that you control ..." - The problem is that if the user is diddling the clocks to get round an expired license key, then they could also block the app's access to the external time source, or redirect the connection to a fake time server. – Gratification

Answer 2

java.util.Date is in Core java API Since JDK1.0 But java.time.LocalDate is introduced in Java API in version 1.8 version of java.

The LocalDate represents a date in ISO format (yyyy-MM-dd) without time.It can be used to store dates like birthdays and paydays.

Actually this new Time-Date is introduced in Java 1.8 to provide immutability and thread safety. And to provide wide variety of utility methods that support the commonest operations.

You Can Refer following for more details :

Difference Between Two Dates in Java

Working with Java 8 date-time

Crossbeam

Answer 3

For the general question about the differences between java.util.Date and java.time.LocalDate I recommend that you take the time to read the respective javadoc, or an article on transitioning to the Java 8 time APIs. There are a lot of differences: too many to list.

(The general recommendation is to not use java.util.Date in new code: treat it as a legacy class.)

On the specific question that I think you are asking about "manipulation" of clocks, BOTH java.util.Date AND java.time.LocalDate get their time information from the system clock on the user's machine. So if the user has been "manipulating" the system clock to report bogus time information, then both of these classes will report that bogus information.

More generally, there is no class in the Java SE class library that will report trust-worthy information if the user has manipulated the clocks. (Even if there was such a class, the user could modify the relevant Java library to circumvent that. And if you put the smarts into your code, the user could circumvent that too.)

Note that this is not a Java-specific problem. Any application that runs on a machine controlled by a non-trustworthy user could be interfered with ... irrespective of the programming language. If you provide the user with your software to run on their machine you have ceded control of what they can do with it. (If they try hard enough.)

Finally, if the problem you are trying to address is that the user's local clock is out of sync with internet time sources, this is not really a problem for an application to deal with. Users (or their systems people) should address this.

Gratification