何时何地更适合？
我不确切知道它们之间究竟存在什么差异。
的文档...时间表示为纳秒精度。例如，值“2007年10月2日13：45.30.123456789”可以 存储在LocalDateTime中。
我假设LocalDateTime也可以接受纳秒。所以我认为，我可以用LocalDateTime替换我的代码，这些代码被声明为TimeStamp。如果我错了，请纠正我。
场景：我们计划用Java-8升级我们的项目。修改了具有JAVA-8新功能的旧代码样式（例如：Lambda，Streams等;）。但是我们在决定日期和时间时遇到了麻烦。大多数java.util.Date代码已更改为java.time.LocalDate或java.time.LocalDateTime。对于TimeStamp的情况，我不知道问题
我们应该用LocalDateTime替换它们吗？
答案 0 :(得分：6)
在当前的开发中，您应该更喜欢LocalDateTime和其他Java8时间类。
它们提供了时间点定义（Instant）和持续时间（Duration）或基于片段的定义（LocalDate，{LocalTime之间更清晰分离的优势。 {1}}）。
它们允许一组非常好的操作/计算逻辑方法（与java.util.Date不同）。
还包括单位转换（Duration.toDays()）。
最后但并非最不重要的是时区地狱（ZonedDateTime）。
缺点是您可能希望利用相当多的第三方API缺乏支持。但这应该只是一个时间问题，从Java8时间API到日历/日期的转换是没有显示的。
如果你有一个成熟的软件，那么用基于Java8的接口替换旧的基于日期/日历的接口只是一个风险，直到你利用上面提到的一些优点。
如果您想用旧的TimeStamp参数替换Java8时间工具箱之外的内容，那么您可以使用Instant，LocalDateTime或ZonedDateTime。不同之处在于Instant值在计算时基于ZoneOffset.UTC处理，而LocalDateTime按定义则没有任何时区关系。
提示：使用LocalDateTime是一件非常好的事情，如果2018-01-02 10:24:12的某些事情发生在例如{1}}的系统中。印度和美国的制度。在几乎所有其他情况下，您可能更愿意使用Instant或ZonedDateTime明确定义时区。
答案 1 :(得分：3)
java.util.Date和java.sql.Timestamp实际上等同于java.time.Instant，而不是LocalDateTime，日期时间戳和即时是Unix time的实例，而LocalDateTime是当前时区的日期时间。
你可以清楚地看到，因为这两个类都有这个很好的方法（继承自java.util.Date）：
java.util.Date::toInstant
我认为将Date替换为LocalDate意味着您实际上是在替换java.sql.Date，而不是java.util.Date。现在，sql.Date相当于LocalDate，并不等同于Instant，因为sql.Date缺少Time组件（尽管sql.Date是util.Date的子类，在它上面调用getSeconds()会导致异常）