简短的回答：

Date in = new Date();
LocalDateTime ldt = LocalDateTime.ofInstant(in.toInstant(), ZoneId.systemDefault());
Date out = Date.from(ldt.atZone(ZoneId.systemDefault()).toInstant());

解释：（基于this question about LocalDate）

尽管它的名字，java.util.Date代表时间线上的瞬间，而不是“日期”。存储在对象中的实际数据是long自
1970-01-01T00:00Z（1970 GMT/UTC 开始时的午夜）以来的毫秒数。

JSR-310 中的等价类java.util.Date是Instant，因此有方便的方法来提供来回转换：

Date input = new Date();
Instant instant = input.toInstant();
Date output = Date.from(instant);

java.util.Date实例没有时区的概念。如果您调用toString()a
，这可能看起来很奇怪java.util.Date，因为atoString是相对于时区的。然而，该方法实际上使用 Java
的默认时区来提供字符串。时区不是 的实际状态的一部分java.util.Date。

AnInstant也不包含有关时区的任何信息。因此，要从一个日期时间转换Instant为本地日期时间，必须指定一个时区。这可能是默认时区 -
ZoneId.systemDefault()-
或者它可能是您的应用程序控制的时区，例如来自用户首选项的时区。LocalDateTime有一个方便的工厂方法，它同时采用即时和时区：

Date in = new Date();
LocalDateTime ldt = LocalDateTime.ofInstant(in.toInstant(), ZoneId.systemDefault());

相反，LocalDateTime时区是通过调用该atZone(ZoneId)方法来指定的。然后ZonedDateTime可以直接将其转换为Instant：

LocalDateTime ldt = ...
ZonedDateTime zdt = ldt.atZone(ZoneId.systemDefault());
Date output = Date.from(zdt.toInstant());

请注意，从LocalDateTimeto的转换ZonedDateTime可能会引入意外行为。这是因为由于夏令时，并非每个本地日期时间都存在。在秋季/秋季，本地时间线存在重叠，相同的本地日期时间出现两次。在春天，有一个间隙，一个小时消失了。atZone(ZoneId)有关转换将做什么的更多定义，请参见 Javadoc 。

总结，如果你往返 ajava.util.Date到 aLocalDateTime并返回到 a
java.util.Date，由于夏令时，你最终可能会得到不同的瞬间。

附加信息：还有另一个差异会影响非常旧的日期。java.util.Date使用在 1582 年 10 月 15
日更改的日历，在此之前的日期使用儒略历而不是公历。相比之下，java.time.*一直使用 ISO 日历系统（相当于公历）。在大多数用例中，您需要
ISO 日历系统，但在比较 1582 年之前的日期时，您可能会看到奇怪的效果。