更新为了更正:
在大多数情况下是一样的,请参阅巴西从冬季转为夏季的例子:
ZonedDateTime zdt =
ZonedDateTime.of(2015, 10, 18, 0, 30, 0, 0,
ZoneId.of("America/Sao_Paulo")); // switch to summer time
ZonedDateTime zdt1 = zdt.truncatedTo(ChronoUnit.DAYS);
ZonedDateTime zdt2 = zdt.toLocalDate().atStartOfDay(zdt.getZone());
System.out.println(zdt); // 2015-10-18T01:30-02:00[America/Sao_Paulo]
System.out.println(zdt1); // 2015-10-18T01:00-02:00[America/Sao_Paulo]
System.out.println(zdt2); // 2015-10-18T01:00-02:00[America/Sao_Paulo]
截断发生在本地时间轴上。如果你选择DAYS,那么你选择午夜。根据javadoc,truncate() – 方法终于转换回新的ZonedDateTime,并将时间向前移动距离的大小(1小时)。
将zdt首先转换为LocalDate(切断时间部分),然后在给定的时区中查找其ZonedDateTime部分对于这种情况是有效的。
然而,从夏季到冬季的倒退情况,有一个例外(非常感谢@Austin谁给了一个反例)。问题是在重叠时决定要使用哪个偏移量。通常,ZonedDateTime类被设计/指定使用以前的偏移量,另请参见Javadoc的摘录:
For Overlaps, the general strategy is that if the local date-time
falls in the middle of an Overlap, then the previous offset will be
retained. If there is no previous offset, or the previous offset is
invalid, then the earlier offset is used, typically “summer” time.
如果ZonedDateTime类遵循自己的规范,那么这两个过程仍然是等效的意思:
zdt.truncatedTo(ChronoUnit.DAYS);
应该相当于
zdt.toLocalDate().atStartOfDay().atZone(zdt.getZone()).withEarlierOffsetAtOverlap();
但是,根据@Austin的例子,我自己测试证实的真实行为是:
zdt.toLocalDate().atStartOfDay().atZone(zdt.getZone()).withLaterOffsetAtOverlap();
看起来像ZonedDateTime类中隐藏的不一致,轻声说。如果你问我哪个方法是首选,那么我宁愿主张第二种方法,虽然它要长得多,需要更多的击键。但是它对于它的作用更加透明是有很大的优势的。选择第二种方法的另一个原因是:
它真的获得了当地时间等于一天开始的第一瞬间。否则,使用第一种方法时,您必须写:
zdt.truncatedTo(ChronoUnit.DAYS).withEarlierOffsetAtOverlap();