程序员的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的神速之时,其他程序员也以测试的方式验证了这一结果的正确——美国时间木有这个问题。看来,当一枚程序员,有时真的需要上通天文、下知地理啊……
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
· 10年+ .NET Coder 心语 ── 封装的思维:从隐藏、稳定开始理解其本质意义
· 地球OL攻略 —— 某应届生求职总结
· 提示词工程——AI应用必不可少的技术
· Open-Sora 2.0 重磅开源!
· 周边上新:园子的第一款马克杯温暖上架