为什么减去这两次（在1927年）给出一个奇怪的结果？

作者: 薄情
发布时间: 2025-02-05 10:18:45 (5天前)
转自：

9 条回复

0#
回复此人
谦成 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 我很遗憾地说，但是时间的不连续性已经发生了变化 </p> <P> <a href="https://en.wikipedia.org/wiki/Java_version_history#Java_SE_6_.28December_11.2C_2006.29" rel="noreferrer"> JDK 6 </A> 两年前，在 <a href="https://en.wikipedia.org/wiki/Java_version_history#Java_SE_7_.28July_28.2C_2011.29" rel="noreferrer"> JDK 7 </A> 就在最近 <a href="https://en.wikipedia.org/wiki/Java_version_history#cite_note-131" rel="noreferrer"> 更新25 </A> 。 </p> <P> 要学习的课程：不惜一切代价避免非UTC时间，除了显示。 </p> </DIV>

编辑
1#
回复此人
没身份别烦我 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 您可以使用以下代码，而不是转换每个日期 </p> <pre> <code> long difference = (sDt4.getTime() - sDt3.getTime()) / 1000; System.out.println(difference); </code> </pre> <P> 并看到结果是： </p> <pre> <code> 1 </code> </pre> </DIV>

编辑
2#
回复此人
不易青年。 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 在递增时间时，您应该转换回UTC然后加或减。仅使用当地时间进行显示。 </p> <P> 通过这种方式，您可以在几小时或几分钟发生两次的任何时段走过。 </p> <P> 如果转换为UTC，请添加每秒，然后转换为本地时间进行显示。你会经过晚上11:54:08。 <a href="http://en.wikipedia.org/wiki/Local_mean_time" rel="noreferrer"> LMT </A> - 下午11:59:59 LMT然后是晚上11:54:08 <a href="http://en.wikipedia.org/wiki/Central_Time_Zone_%28North_America%29" rel="noreferrer"> CST </A> - 下午11:59:59 CST。 </p> </DIV>

编辑
3#
回复此人
回忆氵独奏♪ | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 恕我直言，无处不在， <EM> 含蓄 </EM> Java中的本地化是其最大的设计缺陷。它可能适用于用户界面，但坦率地说，现在谁真正使用Java作为用户界面，除了一些IDE，你基本上可以忽略本地化，因为程序员并不是它的目标受众。您可以通过以下方式修复它（特别是在Linux服务器上）： </p> <UL> <LI> export LC_ALL = C TZ = UTC </LI> <LI> 将系统时钟设置为UTC </LI> <LI> 除非绝对必要，否则永远不要使用本地化的实现 </LI> </UL> <P> 到了 <a href="https://www.jcp.org/" rel="noreferrer"> Java社区流程 </A> 我推荐的成员： </p> <UL> <LI> 使本地化方法不是默认方法，但要求用户明确请求本地化。 </LI> <LI> 使用UTF-8 / UTC作为 <EM> 固定 </EM> 默认，因为这只是今天的默认值。除非您想生成这样的线程，否则没有理由做其他事情。 </LI> </UL> <P> 我的意思是，来吧，不是全局静态变量是反OO模式吗？没有其他东西是由一些基本的环境变量给出的那些普遍的默认值....... </p> </DIV>

编辑
4#
回复此人
v-star*위위 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 你遇到了一个 <a href="http://timeanddate.com/worldclock/clockchange.html?n=237&year=1927" rel="noreferrer"> 当地时间不连续 </A> ： </p> <BLOCKQUOTE> <P> 当地标准时间即将到达星期日，1928年1月1日， 00:00:00时钟倒退0:05:52至星期六，31。 1927年12月，当地标准时间23:54:08代替 </p> </BLOCKQUOTE> <P> 这并不是特别奇怪，并且由于政治或行政行为导致时区被切换或改变，因此在任何时候都发生过这种情况。 </p> </DIV>

编辑
5#
回复此人
甲基蓝 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 这种陌生感的道德是： </p> <UL> <LI> 尽可能使用UTC中的日期和时间。 </LI> <LI> 如果您无法以UTC格式显示日期或时间，请始终指明时区。 </LI> <LI> 如果您不能要求以UTC格式输入日期/时间，则需要明确指定的时区。 </LI> </UL> </DIV>

编辑
6#
回复此人
哇。 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 正如其他人所解释的那样，那里有一段时间不连续。有两种可能的时区偏移 <code> 1927-12-31 23:54:08 </code> 在 <code> Asia/Shanghai </code> ，但只有一个偏移 <code> 1927-12-31 23:54:07 </code> 。因此，根据使用的偏移量，存在一秒差异或5分53秒差异。 </p> <P> 这种轻微的偏移转移，而不是我们习惯的通常的一小时夏令时（夏令时），有点模糊了问题。 </p> <P> 请注意，时区数据库的2013a更新在几秒钟之前移动了此不连续性，但效果仍然可以观察到。 </p> <P> 新的 <code> java.time </code> Java 8上的包使用更清楚地看到它，并提供处理它的工具。鉴于： </p> <pre> <code> DateTimeFormatterBuilder dtfb = new DateTimeFormatterBuilder(); dtfb.append(DateTimeFormatter.ISO_LOCAL_DATE); dtfb.appendLiteral(' '); dtfb.append(DateTimeFormatter.ISO_LOCAL_TIME); DateTimeFormatter dtf = dtfb.toFormatter(); ZoneId shanghai = ZoneId.of("Asia/Shanghai"); String str3 = "1927-12-31 23:54:07"; String str4 = "1927-12-31 23:54:08"; ZonedDateTime zdt3 = LocalDateTime.parse(str3, dtf).atZone(shanghai); ZonedDateTime zdt4 = LocalDateTime.parse(str4, dtf).atZone(shanghai); Duration durationAtEarlierOffset = Duration.between(zdt3.withEarlierOffsetAtOverlap(), zdt4.withEarlierOffsetAtOverlap()); Duration durationAtLaterOffset = Duration.between(zdt3.withLaterOffsetAtOverlap(), zdt4.withLaterOffsetAtOverlap()); </code> </pre> <P> 然后 <code> durationAtEarlierOffset </code> 将是一秒钟，而 <code> durationAtLaterOffset </code> 将是五分53秒。 </p> <P> 此外，这两个偏移是相同的： </p> <pre> <code> // Both have offsets +08:05:52 ZoneOffset zo3Earlier = zdt3.withEarlierOffsetAtOverlap().getOffset(); ZoneOffset zo3Later = zdt3.withLaterOffsetAtOverlap().getOffset(); </code> </pre> <P> 但这两者是不同的： </p> <pre> <code> // +08:05:52 ZoneOffset zo4Earlier = zdt4.withEarlierOffsetAtOverlap().getOffset(); // +08:00 ZoneOffset zo4Later = zdt4.withLaterOffsetAtOverlap().getOffset(); </code> </pre> <P> 您可以看到比较相同的问题 <code> 1927-12-31 23:59:59 </code> 同 <code> 1928-01-01 00:00:00 </code> 但是，在这种情况下，它是较早的偏移产生较长的偏差，而较早的日期有两个可能的偏移。 </p> <P> 另一种方法是检查是否正在进行转换。我们可以这样做： </p> <pre> <code> // Null ZoneOffsetTransition zot3 = shanghai.getRules().getTransition(ld3.toLocalDateTime); // An overlap transition ZoneOffsetTransition zot4 = shanghai.getRules().getTransition(ld3.toLocalDateTime); </code> </pre> <P> 您可以检查转换是否是重叠 - 在这种情况下，该日期/时间有多个有效偏移量 - 或者是间隙 - 在这种情况下，日期/时间对于该区域ID无效 - 通过使用 <code> isOverlap() </code> 和 <code> isGap() </code> 方法 <code> zot4 </code> 。 </p> <P> 我希望这有助于人们在Java 8广泛使用后处理这类问题，或者使用采用JSR 310 backport的Java 7的人。 </p> </DIV>

编辑
7#
回复此人
庸人自扰 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> <P> 正如其他人所提到的，这是1927年在上海的时间变化。 </p> <P> 基本上，那 <code> 23:54:07 </code> 在上海，当地的标准时间，过了一会儿，它转向第二天 <code> 00:00:00 </code> 。但后来又转回了 <code> 23:54:08 </code> 为当地标准时间。所以，这就是为什么差异是343秒而不是1秒。 </p> <P> 这也可以搞砸美国等其他地方。在美国，他们有夏令时。当夏令时开始时，时间前进1小时。但过了一段时间夏令时结束后，它会向后退一小时回到标准时区。因此，有时在比较美国的时间差异时 <code> 3600 </code> 秒不是1秒。 </p> <P> 的<strong> 最好在时间不变的情况下使用UTC，除非在显示时需要使用非UTC时间。 </强> </p> </DIV>

编辑

登录后才能参与评论