飞码网-免费源码博客分享网站

点击这里给我发消息

为什么减去两次(in 1927) 会得到一个奇怪的结果?|-Javascript教程

飞码网-免费源码博客分享网站 爱上飞码网—https://www.codefrees.com— 飞码网-matlab-python-C++ 爱上飞码网—https://www.codefrees.com— 飞码网-免费源码博客分享网站

问:

如果我运行以下程序,则该程序将分析两个日期字符串(相隔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(正如我从一秒钟的时间差中期望的那样),但是353呢?

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

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

然后ld4-ld31

答:

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

有关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秒变化(这样的时间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假定这是一个有效的概念),因此其他库不需要引入这种人为的转换。

飞码网-免费源码博客分享网站 爱上飞码网—https://www.codefrees.com— 飞码网-matlab-python-C++ 爱上飞码网—https://www.codefrees.com— 飞码网-免费源码博客分享网站
赞 ()
内容页底部广告位3
留言与评论(共有 0 条评论)
   
验证码: