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

Question

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

在Java9中，Duration类获得了方便的to…Part方法：toDaysPart、toHoursPart、toMinutesPart、toSecondsPart、toMillisPart、toNanosPart。我理解对时间、分钟等的需求，但我想知道toDaysPart的情况。

我的问题是：

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

Answer 1

在Java11中，OpenJDK中的这些源代码行都是，与完全相同。

Duration#toDays

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

Duration#toDaysPart

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

截至Java 16，没有指示哪个是不推荐的，哪些是不推荐的。So...keep你的眼睛为它剥皮，是我能给你最好的建议在这里。

Answer 2

这些方法不只是做相同的事情；它们被指定为在文档中执行相同的操作(在您的问题中链接)：

public long toDays() 获取此持续时间内的天数。它返回持续时间中的总天数，方法是将秒数除以86400。这是基于一天24小时的标准定义。此实例是不可变的，不受此方法调用的影响。 返回:持续时间中的天数可能为负public long toDaysPart()。 提取持续时间中的天数。它返回持续时间中的总天数，方法是将秒数除以86400。这是基于一天24小时的标准定义。此实例是不可变的，不受此方法调用的影响。 返回:持续期间的天数可能为负数。

唯一的区别是描述性摘要中的“获取”与“提取”一词。这些词在这个上下文中没有不同的含义，其余的是逐字相同的，特别是指定方法返回的部分是相同的。事实上，用于OpenJDK的( toDaysPart )文档是最近改变了，以澄清这些方法做同样的事情。所以是的，它们是多余的。

根据相关问题关于问题跟踪器的说法，所有的to...Part方法都是加在一起的，对于toDaysPart将是多余的这一事实没有任何评论；所以我们只能推测添加冗余方法的理由。

Answer 3

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