java - 为什么将这两次相减（在1927年）会得出奇怪的结果？(Why is subtracting these two times (in 1927) giving a strange result?)

Question

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

(如果我运行以下程序，该程序将解析两个日期字符串，它们分别引用间隔为1秒的时间并进行比较：)

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

(353)

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

(为什么ld4-ld3不是1 （就像我从一秒的时间差中期望的那样），而是353 ？)

If I change the dates to times 1 second later:

(如果我将日期更改为1秒后的时间：)

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

Then ld4-ld3 will be 1 .

(然后ld4-ld3将为1 。)

---

Java version:

(Java版本：)

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

  ask by Freewind translate from so

Answer 1

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

(这是12月31日在上海的时区更改。)

See this page for details of 1927 in Shanghai.

(有关1927年上海的详细信息，请参见此页 。)

Basically at midnight at the end of 1927, the clocks went back 5 minutes and 52 seconds.

(基本上在1927年底的午夜，时钟回到了5分52秒。)

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.

(因此，“ 1927-12-31 23:54:08”实际上发生了两次，看起来Java正在将其解析为该本地日期/时间的稍后可能时刻，因此有所不同。)

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 .

(如果使用TZDB的2013a版本进行重建，原始问题将不再表现出完全相同的行为。)

In 2013a, the result would be 358 seconds, with a transition time of 23:54:03 instead of 23:54:08.

(在2013a中，结果为358秒，转换时间为23:54:03，而不是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.

(我之所以注意到这一点，是因为我在Noda Time以单元测试的形式收集了类似的问题……测试现已更改，但这只是显示出来-甚至历史数据也不安全。)

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).

(在TZDB 2014f中，更改时间已移至1900-12-31，现在仅更改了343秒（因此，如果您明白我的意思，那么t和t+1之间的时间为344秒）。)

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:

(编辑：要回答有关1900年过渡的问题...似乎Java时区实现将所有时区都视为在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.

(上面的代码在Windows计算机上不产生任何输出。)

So any time zone which has any offset other than its standard one at the start of 1900 will count that as a transition.

(因此，任何在1900年初具有除标准偏移量之外的偏移量的时区都将被视为过渡。)

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.

(TZDB本身具有一些早于此的数据，并且不依赖于任何“固定的”标准时间（这是getRawOffset认为是有效的概念）的概念，因此其他库不需要引入这种人为的转换。)