Java

有关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

编辑：要回答有关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