• 程序员的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的神速之时,其他程序员也以测试的方式验证了这一结果的正确——美国时间木有这个问题。看来,当一枚程序员,有时真的需要上通天文、下知地理啊……

  • 相关阅读:
    搞破坏(手动滑稽),如何写出让同事无法维护的代码?
    我们公司是如何把项目中的2100个if-else彻底干掉的
    为什么阿里规定需在事务注解@Transactional中指定rollbackFor?
    算法导论 10.2-7
    算法导论 10.2-3
    算法导论 10.2-2
    算法导论 10.1-7
    算法导论 10.1-6
    算法导论 2.3-7
    算法导论 2.3-5 二分查找
  • 原文地址:https://www.cnblogs.com/dabaopku/p/2572419.html
Copyright © 2020-2023  润新知