zoukankan      html  css  js  c++  java
  • 程序员的1927年12月31日午夜一秒谜案

    来源:http://news.cnd8.com/news/48702.htm

    虽说是程序员问的,不过内容和编程本身其实并没什么太大关系,请各位听我细细道来。StackOverflow是一个程序员向的问答网站,广大程序员们在上面交流经验、提问答疑,三天前,一位名叫Freewind的用户发布了下面这个问题:
      

    我在用Java编写一段比较两个字符串时间间隔的程序,然而当我比较“1927-12-3123:54:07”和“1927-12-3123:54:08”这两个时间时,输出结果却不是1……而是353。
      
    当我把两个时间分别往后调整1秒,变成“1927-12-3123:54:08”和“1927-12-3123:54:09”,结果就又是1了!——可为什么那两个时间的结果,却是353呢?
      
    面对这一诡异的问题,网友们很快追问,“你的区域(Locale)设置是什么?这可能是个区域问题/和当地夏令时之类的东西有关。”

      
      楼主很快附上了Java版本号和区域设置:

    sun.util.calendar.ZoneInfo[id="Asia/Shanghai",
      
      offset=28800000,dstSavings=0,
      
      useDaylight=false,
      
      transitions=19,
      
      lastRule=null]
    

      (……没错,Freewind君,似乎是一位魔都死程。不知道这里有没有人认识这位老兄?)

      
      在这份追加信息出现仅仅两分钟之后,StackOverflow站上的问答狂人JonSkeet给出了如下答复——
      
      这是因为上海的时区在12月31日发生了变化。
      
      请看这里。(网页截图如下)
      


      (1928年1月1日0点0分,当地时间由地方平时(LocalMeanTime)改为北京时间/中国标准时间)
      
      简单地说,在1927年末的最后那一个午夜,时钟被往回拨了5分52秒。所以“1927-12-3123:54:08”这一秒,事实上,发生了两次,而看起来在计算当地时间时,Java将其视为了后面那一个时间点,于是就产生了这一差别。
      
      这正是时区世界的奇妙与不可思议啊。
      
      在StackFlow网民们纷纷膜拜JonSkeet的神速之时,其他程序员也以测试的方式验证了这一结果的正确——美国时间木有这个问题。看来,当一枚程序员,有时真的需要上通天文、下知地理啊……

  • 相关阅读:
    setup slack检查
    关于derive_pll_clock
    STA中的postmap和postfit
    sdc中对I/O口的约束set_input/output_delay
    hold slack的计算
    DDR I 和DDR II的简单比较
    ORA00600: 内部错误代码,参数: [kcratr1_lostwrt], [], [], [], [], [], [], []
    linux解压超过2G大文件
    linux 安装apache2.2.4
    plsql developer导出csv乱码问题
  • 原文地址:https://www.cnblogs.com/dabaopku/p/2572419.html
Copyright © 2011-2022 走看看