将 time4j Duration<IsoUnit> 从 P365D 转换为 P1Y 等等

Converting time4j Duration<IsoUnit> from P365D to P1Y and so on

Instant i1 = Instant.now();
Instant i2 = Instant.now().plusSeconds(60 * 60 * 24 * 365);
Duration<IsoUnit> dur = Duration.from((TemporalAmount) java.time.Duration.between(i1, i2));
System.out.println(dur);

此代码打印 P365D,有没有办法让单位填满下一个更大的单位,所以这变成 P1Y,如果我想要 P334D 到 P11M 等等?

time4j 版本为 4.38

一年没有固定的秒数:

  1. 闰年在 2 月 29 日多了一天
  2. Leap seconds有时会加上

由于上述原因,您必须知道一年有多少秒。似乎您应该使用 LocalDatePeriod 而不是 InstantDuration(至少在使用 java.time 时):

LocalDate d1 = LocalDate.now();
LocalDate d2 = d1.plusYears(1);
Period p = Period.between(d1, d2);
System.out.println(p); // P1Y

其他的评论和回答说一年不等于365天是完全正确的

Time4J 方法 net.time4j.Duration.from(TemporalAmount) returns 使用 STD_PERIOD 作为标准化器的标准化持续时间。这个标准化器的文档说:

Normalizes the duration items on the base of 1 year = 12 months and 1 day = 24 hours and 1 hour = 60 minutes and 1 minute = 60 seconds - without converting days to months.

因此,当您从以秒为单位定义的时间量开始时,您只能期望结果以天为单位。

如果您仍然想要一年,那么我建议您首先使用适当的时区将您的瞬间转换为日历日期。但是在闰年,你的代码仍然会产生 365 天,而不是在第二个瞬间增加 60 * 60 * 24 * 365 秒后的一年。所以你添加的秒数也是有缺陷的,因为它是基于错误的假设。

旁注:

如果你想要相反的方式,即一年有多少秒,那么你可以使用像

这样的代码
Moment m1 = Moment.nowInSystemTime();
Moment m2 = m1.toZonalTimestamp(ZonalOffset.UTC).plus(1, CalendarUnit.YEARS).atUTC();
long seconds = SI.SECONDS.between(m1, m2); // = 366 days in seconds if applied on date 2019-05-22!

随着 Time4J 的未来版本和 2019 年底可能的闰秒,代码甚至可能产生额外的一秒。

无论如何,我建议您将 Time4J 更新到 v5.4 并考虑以下映射:

java.time.Instant as input => net.time4j.MachineTime.from(...)
java.time.LocalDateTime/net.time4j.PlainTimestamp => net.time4j.Duration.from(...)

因此,如果您确实希望在打印持续时间中输出尽可能多的年份并且您有 instants/moments,那么在创建适当的持续时间对象之前首先转换为 LocalDateTime/PlainTimestamp(使用时区或偏移量)。

2019-05-25 更新:

通过 "fuzzy" 持续时间可以使用版本 v5.4(或更高版本)的另一种方式。您可以通过应用近似值来归一化您获得的持续时间。示例:

    Duration<IsoUnit> d = Duration.of(60 * 60 * 24 * 365, ClockUnit.SECONDS);
    d = d.with(Duration.approximateMaxUnitOnly());
    System.out.println(d); // P1Y

由于这种规范化的性质,您无法期待准确的结果。