Return to Answer

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 local clock is not properly sync'd with internet time sources, this is not really a problem for an application to deal with. The user (or their systems people) should address this.

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.

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.)

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 local clock is not properly sync'd with internet time sources, this is not really a problem for an application to deal with. The user (or their systems people) should address this.

For the general differences between java.util.Date and java.time.LocalDate I recommend that you take the time to read the respective javadocs.

On the specific question that (I think) you are asking, 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, 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 short-coming. Any application that runs on a machine controlled by a non-trust-worthy user can be interfered with ... irrespective of the programming language.

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.)