协慌网

登录 贡献 社区

为什么减去这两次(在 1927 年)给出一个奇怪的结果?

如果我运行以下程序,它解析引用时间间隔为 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);
}

输出是:

353

为什么ld4-ld3不是1 (正如我所预期的那样,时间ld4-ld3 1秒),但353

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

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

然后ld4-ld3将为1


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

答案

这是 12 月 31 日在上海的时区变化。

有关 1927 年在上海的详细信息,请参阅此页 。基本上在 1927 年底的午夜,时钟倒流了 5 分 52 秒。所以 “1927-12-31 23:54:08” 实际上发生了两次,看起来 Java 正在将其解析为当地日期 / 时间的后续可能时刻 - 因此差异。

只是在经常奇怪和精彩的时区世界的另一集。

编辑:停止按!历史变迁......

原来的问题将不再表现出不尽相同的行为,如果与重建版本 2013a TZDB 。在 2013a 中,结果为 358 秒,转换时间为 23:54:03 而不是 23:54:08。

我只注意到这一点,因为我在 Noda Time 中以单元测试的形式收集这样的问题...... 测试现在已经改变了,但它只是显示 - 甚至历史数据都不安全。

编辑:历史再次发生变化......

在 TZDB 2014f 中,更改的时间已经变为 1900-12-31,现在只有 343 秒的变化(所以tt+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假定为有效概念),因此其他库不需要引入这种人工转换。

您遇到了当地时间不连续

当地标准时间即将到达星期日时,1928 年 1 月 1 日 00:00:00 时钟倒退 0:05:52 到星期六,31。1927 年 12 月 31 日,当地标准时间 23:54:08

这并不是特别奇怪,并且由于政治或行政行为导致时区被切换或改变,因此在任何时候都发生过这种情况。

这种陌生感的道德是:

  • 尽可能使用 UTC 中的日期和时间。
  • 如果您无法以 UTC 格式显示日期或时间,请始终指明时区。
  • 如果您不能要求以 UTC 格式输入日期 / 时间,则需要明确指定的时区。