Duration#toDays 和 Duration#toDaysPart 是多余的吗？

问题描述

在 Java 8 中，Duration 类提供了 toDays 方法，以与日历天无关的 24 小时时间块的计数形式返回总天数。

在 Java 9 中，Duration 类获得了方便的 to…Part 方法：toDaysPart、toHoursPart、toMinutesPart、toSecondsPart、{{1 }}，toMillisPart。我了解需要小时、分钟等。但我对 toNanosPart 感到疑惑。

我的问题是：

➥ Duration#toDays 和 Duration#toDaysPart 是否会为特定的 toDaysPart 对象返回不同的值？

解决方法

在 Java 11 中，OpenJDK 中的这些源代码行完全相同。

Duration#toDays：

public long toDays() {
    return seconds / SECONDS_PER_DAY;
}

Duration#toDaysPart

public long toDaysPart(){
    return seconds / SECONDS_PER_DAY;
}

As of Java 16，没有说明哪些已被弃用或哪些不是。所以……睁大你的眼睛吧，这是我在这里能给你的最好的建议。

,

这些方法不只是做同样的事情；他们在文档中指定做同样的事情（链接在你的问题中）：

public long toDays()

获取此持续时间的天数。 这通过将秒数除以 86400 返回持续时间中的总天数。这是基于一天的标准定义为 24 小时。 此实例是不可变的，不受此方法调用的影响。

返回： 持续时间的天数，可能为负

public long toDaysPart()

提取持续时间的天数。 这通过将秒数除以 86400 返回持续时间中的总天数。这是基于一天的标准定义为 24 小时。 此实例是不可变的，不受此方法调用的影响。

返回： 持续时间的天数，可能为负

唯一的区别是描述性摘要中的“获取”与“提取”一词。这些词在此上下文中没有不同的含义，其余部分是逐字相同的，特别是指定方法返回内容的部分是相同的。事实上，toDaysPart 的 (OpenJDK) 文档是 recently changed 来阐明这些方法做同样的事情。所以是的，它们是多余的。

根据问题跟踪器上的 the relevant issue，所有 to...Part 方法都加在一起，没有任何评论 toDaysPart 是多余的；所以我们只能推测添加冗余方法的基本原理。

,

继承自 get(TemporalUnit) 的 TemporalAmount（以及 getSeconds() 和奇怪命名的 getNano()）的目的是支持提取组合值的时间分量. Duration 实际上只支持 SECONDS 和 NANOS 组件访问，因为 Duration 是一个 long 秒组件和一个 int 纳秒组件的组合，它们共同提供纳秒分辨率和表示高达 2^63 秒（正负）的有向值。 get_ 访问器返回仅命名的组件，而 to_ 方法返回覆盖到目标单元的复合整体值。最后，to_Part 上的 Duration 方法模拟 get_ 方法的行为，如果 Duration 被想象为由每个 ChronoUnit 值的一个实例组成。此虚拟组件访问中的奇数是 toDaysPart。我怀疑这样做的原因是，虽然 HOURS、MINUTES、SECONDS、MILLIS、MICROS 和 NANOS 就它们所引用的组件而言可以被视为离散且不重叠的，但在将 DAYS 作为组件值考虑时，我们的意思是不清楚一周中的哪一天、一个月中的哪一天或一年中的哪一天——这三个都是常见的约定。类似地，MONTHS 和 YEARS 的长度都是可变的。因此，作者似乎选择了明确并认为 DAYS 代表该层次结构中最粗糙的组件。我个人认为这有点像狗的早餐，我想知道为什么这两种方法在得出这个结论之前有一段时间是相同的。