有关1927年上海的详细信息,。基本上在1927年底的午夜,时钟回到了5分52秒。因此,“ 1927-12-31 23:54:08”实际上发生了两次,看起来Java正在将其解析为该本地日期/时间的稍后可能时刻,因此有所不同。
在时区通常又怪异而美妙的世界中,又是另一集。
:停止按!历史发生变化…
如果使用TZDB的2013a版本进行重建,原始问题将不再表现出完全相同的行为。在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 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);
}
}
}
}
上面的代码在Windows计算机上不产生任何输出。因此,任何在1900年初具有除标准偏移量之外的偏移量的时区都将被视为过渡。TZDB本身早有一些数据,并且不依赖任何“固定”标准时间的想法(这是getRawOffset
一个有效的概念),因此其他库不需要引入这种人为的转换。
你遇到了当地时间不连续性:
当当地标准时间即将达到星期日1月1日。将1928年1月00:00:00的时钟向后调0:05:52小时到31.星期六。1927年12月,将当地标准时间改为23:54:08
这并不是特别奇怪,并且由于政治或行政行为而改变或更改了时区,一次或多次发生在各地。