为什么在 Java 中没有用于 Date 到 LocalDate 的简单 inbult 转换器？

Question

对设计选择感到好奇 - 是否有任何权威来源关于没有为 LocalDate -> Date 提供简单转换器的设计决策，反之亦然？

我厌倦了用完全笨重的东西来移动这些物体

java.util.Date.from(dateToConvert.atStartOfDay()
  .atZone(ZoneId.systemDefault())
  .toInstant());

而另一个，

dateToConvert.toInstant()
  .atZone(ZoneId.systemDefault())
  .toLocalDateTime();

虽然我知道我不能拥有 date.toLocalDate(nullable ZoneId)，但至少知道为什么会有一些用处（如果只是这样，我永远不会证明使用相同逻辑的决定是合理的）。

Answer 1

您可能会问为什么没有内置的转换方法将 File 对象转换为整数：这 2 种类型几乎完全不相关。

但是，我听到你说，拿着电话，rzwitserloot！你到底在搞什么？Date并且LocalDate是无关的？？？

对，他们是。

因为java.util.Date是一个愚蠢的名字。那不是j.u.Date代表什么；这就是不推荐使用此对象中所有与日期相关的方法的原因。一旦你看到一个名为的类Date有一个被调用的方法getHours，希望它应该是一个很好的指示，无论是谁命名它，让我们继续“休息一天”。那不是没有日期。

j.u.Date代表'一个时刻'。它完全等同于java.time.Instant. 它的内部存储是一个表示 epoch-millis 的 long ，仅此而已。

这与 几乎没有任何关系LocalDate。

是的，许多系统使用j.u.Date对象作为表示LocalDate试图表示的相同概念的一种方式，但那是因为这些系统搞砸了，并且使用了完全不合适的类型。他们可能会被原谅；他们只是落入了和你一样的陷阱：他们被这个班级的名字甩了。

也许有人会争辩说：好吧，但是，嘿，我们生活在这个世界而不是童话世界中，所以考虑到很多次“我需要将其转换j.u.Date为LocalDate”出现，应该更容易，对吧？好吧，仅仅因为它很常见就支持不良行为——让我们说这是否是一个好主意。此外，这项工作从根本上说是非常非常棘手的。我们如何进行这种转换？我是否应该按照j.u.Date对象所代表的时间来检查当前系统默认语言环境中的实际日历日期（例如，转到服务器所在的位置。现在走出大楼。找到一个人。询问他们：现在是什么日期？他们回答什么？） - 或者他们应该去UTC语言环境？（去格林威治问那里。除非是夏天，然后问：一小时前是哪一天？）。

在许多情况下，答案显然不会相同，但两种策略显然都不优于另一种。因此，制作这样一个方便的方法只会引起史诗般的混乱。你错过了一些关键的信息，如果不是更多的话——如果没有进一步的上下文，将 a 转换j.u.Date为 a 的工作LocalDate就无法完成，除非你愿意在每一个丢失的信息上扔硬币。您不妨调用一个Random实例.nextInt(365)来弄清楚。