为什么减去这两次(在 1927 年)会得到一个奇怪的结果? [英] Why is subtracting these two times (in 1927) giving a strange result?

问题描述

如果我运行以下程序，它解析两个引用时间间隔 1 秒的日期字符串并比较它们:

public static void main(String[] args) 抛出 ParseException {SimpleDateFormat sf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");字符串 str3 = "1927-12-31 23:54:07";字符串 str4 = "1927-12-31 23:54:08";日期 sDt3 = sf.parse(str3);日期 sDt4 = sf.parse(str4);长 ld3 = sDt3.getTime()/1000;长 ld4 = sDt4.getTime()/1000;System.out.println(ld4-ld3);}

输出为:

353

为什么是 ld4-ld3，而不是 1(正如我对一秒差异的预期)，而是 353?

如果我将日期更改为 1 秒后的时间:

String str3 = "1927-12-31 23:54:08";字符串 str4 = "1927-12-31 23:54:09";

那么 ld4-ld3 将是 1.

---

Java 版本:

java 版本1.6.0_22"；Java(TM) SE 运行时环境(构建 1.6.0_22-b04)动态代码演化客户端 VM(构建 0.2-b02-internal、19.0-b04-internal、混合模式)

Timezone(`TimeZone.getDefault()`):sun.util.calendar.ZoneInfo[id=亚洲/上海"，偏移=28800000，dstSavings=0，使用日光=假，转换=19，最后一条规则=空]语言环境(Locale.getDefault()): zh_CN

解决方案

上海 12 月 31 日的时区变化.

请参阅此页面，了解 1927 年在上海.基本上在 1927 年底的午夜，时钟倒退了 5 分 52 秒.因此，1927-12-31 23:54:08"实际上发生了两次，看起来 Java 正在将其解析为该本地日期/时间的较晚可能时刻 - 因此存在差异.>

这只是时区经常怪异而美妙的世界中的又一集.

停止按！历史变化...

如果使用 TZDB.在 2013a 中，结果将为 358 秒，转换时间为 23:54:03 而不是 23:54:08.

我之所以注意到这一点，是因为我在 Noda Time 中以 单元测试...测试现在已经改变，但它只是显示 - 甚至历史数据都不安全.

历史再次改变......

在 TZDB 2014f 中，更改时间已移至 1900-12-31，现在更改仅为 343 秒(因此 t 和 t+1 是 344 秒，如果你明白我的意思).

要回答有关 1900 年过渡的问题......看起来 Java 时区实现将所有时区视为简单地处于它们的标准时间1900 UTC 开始前的任何时刻:

import java.util.TimeZone;公共类测试{public static void main(String[] args) 抛出异常 {long startOf1900Utc = -2208988800000L;for (String id : TimeZone.getAvailableIDs()) {TimeZone zone = TimeZone.getTimeZone(id);如果(zone.getRawOffset()！= zone.getOffset(startOf1900Utc - 1)){System.out.println(id);}}}}

上面的代码在我的 Windows 机器上没有产生任何输出.因此，任何在 1900 年初具有除标准偏移之外的任何偏移的时区都将其视为过渡.TZDB 本身有一些比这更早的数据，并且不依赖于任何固定"标准时间的想法(这是 getRawOffset 假定是一个有效的概念)所以其他库需要'不要引入这种人为的过渡.

If I run the following program, which parses two date strings referencing times 1 second apart and compares them:

public static void main(String[] args) throws ParseException {
    SimpleDateFormat sf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");  
    String str3 = "1927-12-31 23:54:07";  
    String str4 = "1927-12-31 23:54:08";  
    Date sDt3 = sf.parse(str3);  
    Date sDt4 = sf.parse(str4);  
    long ld3 = sDt3.getTime() /1000;  
    long ld4 = sDt4.getTime() /1000;
    System.out.println(ld4-ld3);
}

The output is:

353

Why is ld4-ld3, not 1 (as I would expect from the one-second difference in the times), but 353?

If I change the dates to times 1 second later:

String str3 = "1927-12-31 23:54:08";  
String str4 = "1927-12-31 23:54:09";  

Then ld4-ld3 will be 1.

---

Java version:

java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Dynamic Code Evolution Client VM (build 0.2-b02-internal, 19.0-b04-internal, mixed mode)

Timezone(`TimeZone.getDefault()`):

sun.util.calendar.ZoneInfo[id="Asia/Shanghai",
offset=28800000,dstSavings=0,
useDaylight=false,
transitions=19,
lastRule=null]

Locale(Locale.getDefault()): zh_CN

解决方案

It's a time zone change on December 31st in Shanghai.

See this page for details of 1927 in Shanghai. Basically at midnight at the end of 1927, the clocks went back 5 minutes and 52 seconds. So "1927-12-31 23:54:08" actually happened twice, and it looks like Java is parsing it as the later possible instant for that local date/time - hence the difference.

Just another episode in the often weird and wonderful world of time zones.

EDIT: Stop press! History changes...

The original question would no longer demonstrate quite the same behaviour, if rebuilt with version 2013a of TZDB. In 2013a, the result would be 358 seconds, with a transition time of 23:54:03 instead of 23:54:08.

I only noticed this because I'm collecting questions like this in Noda Time, in the form of unit tests... The test has now been changed, but it just goes to show - not even historical data is safe.

EDIT: History has changed again...

In TZDB 2014f, the time of the change has moved to 1900-12-31, and it's now a mere 343 second change (so the time between t and t+1 is 344 seconds, if you see what I mean).

EDIT: To answer a question around a transition at 1900... it looks like the Java timezone implementation treats all time zones as simply being in their standard time for any instant before the start of 1900 UTC:

import java.util.TimeZone;

public class Test {
    public static void main(String[] args) throws Exception {
        long startOf1900Utc = -2208988800000L;
        for (String id : TimeZone.getAvailableIDs()) {
            TimeZone zone = TimeZone.getTimeZone(id);
            if (zone.getRawOffset() != zone.getOffset(startOf1900Utc - 1)) {
                System.out.println(id);
            }
        }
    }
}

The code above produces no output on my Windows machine. So any time zone which has any offset other than its standard one at the start of 1900 will count that as a transition. TZDB itself has some data going back earlier than that, and doesn't rely on any idea of a "fixed" standard time (which is what getRawOffset assumes to be a valid concept) so other libraries needn't introduce this artificial transition.

这篇关于为什么减去这两次(在 1927 年)会得到一个奇怪的结果?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！