在程序里面,时间真的发生了343秒的倒流。(上)

简介: 在程序里面,时间真的发生了343秒的倒流。(上)

你好呀,我是歪歪。

给大家分享一个我最近发现的有点意思,但是卵用不大的小知识点。

先给你搞个程序看一下:

public class MainTest {
    public static void main(String[] args) throws Exception {
        SimpleDateFormat simpleDateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
        Date date = simpleDateFormat.parse("1900-01-01 08:00:00");
        System.out.println(simpleDateFormat.format(date));
    }
}

你说上面的程序逻辑就是一个简单的时间格式化,你说输出结果是什么?

只是需要瞟一眼就知道,肯定是输出这个结果呀:

1900-01-01 08:00:00

但是,你把上面的程序拿出来,直接跑起来,你会发现输出结果竟然是这样的:

1900-01-01 08:05:43

当时就懵逼了。

我知道时差 8 小时,是因为有时区问题。

我知道时间差 1 小时,是因为有夏令时的原因。

但是这里差了 5 分 43 秒,有零有整,就让我有点摸不着头脑了。


image.png

上面这个案例就是一个读者分享给我的,他们在数据库里面默认时间是 1900-01-01,再加上时区问题,刚好变成了 1900-01-01 08:00:00,于是在通过程序做数据迁移的时候就踩到了这个莫名其妙的时间问题。

image.jpeg


同时他还给我附送了一个关于这个 bug 的链接:

https://bugs.openjdk.java.net/browse/JDK-8266262


image.png


我乍一看,这个 bug 还挺新的呢,属于今年提出来的。

仔细又看了一眼发现是和之前的 bug 重复了:


image.png


但是这里提到了原因:

他说可以看一下这个链接https://www.timeanddate.com/time/zone/china/shanghai?year=1900

这里面,在 1900 年的时候,发生了一个变化:

The timezone offset was UTC +8:05:43 hours all of the period.

虽然我没太看明白具体是什么意思,但是我看到了“5 分 43 秒”:


image.png


我理解就是由于时区的变化,导致时间发生了重置。

接着我顺藤摸瓜,在 stackoverflow 上找到了这个:

https://stackoverflow.com/questions/6841333/why-is-subtracting-these-two-times-in-1927-giving-a-strange-result

当时我就震惊了。

这个 10 年前被提出的问题居然已经被浏览过 746k 次了,非常热门的问题了,我居然没注意到过:


image.png

这个问题具体是这样的:

image.png

你就大概瞟一眼,我给你翻译翻译。

提问者说,他发现 1927-12-31 23:54:07 到 1927-12-31 23:54:08 之间差了 353 秒,按理来说应该是 1 秒才对啊?

但是把时间改成下面这样,又正常了:

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

我把程序粘出来你也可以跑一下,看看结果非常的神奇啊:

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 秒呢?

跑出来怎么是 1 秒呢,毫无毛病啊:

image.png

我甚至怀疑是 jdk 版本的问题,于是我换了 jdk 9,11,15 都跑了一下,都是 1 秒。

这就很奇怪了啊。

感觉这个问题提的就有问题啊。

image.png

目录
相关文章
|
人工智能 算法 机器人
字节Coze优缺点分析
【2月更文挑战第16天】字节Coze优缺点分析
3727 2
字节Coze优缺点分析
|
5月前
|
机器学习/深度学习 人工智能 缓存
万字综述,讲一讲这两年大模型这整个领域到底发展了哪些方面
本文深入探讨了自2023年GPT-4发布以来,大型语言模型(LLM)领域的发展趋势及其技术演进路径。
万字综述,讲一讲这两年大模型这整个领域到底发展了哪些方面
|
9月前
|
人工智能 自然语言处理 机器人
今日AI论文推荐:ReCamMaster、PLADIS、SmolDocling、FlowTok
由浙江大学、快手科技等机构提出的ReCamMaster是一个相机控制的生成式视频重渲染框架,可以使用新的相机轨迹重现输入视频的动态场景。该工作的核心创新在于利用预训练的文本到视频模型的生成能力,通过一种简单但强大的视频条件机制。为克服高质量训练数据的稀缺问题,研究者使用虚幻引擎5构建了一个全面的多相机同步视频数据集,涵盖多样化的场景和相机运动。
492 2
今日AI论文推荐:ReCamMaster、PLADIS、SmolDocling、FlowTok
|
7月前
|
存储 缓存 分布式计算
StarRocks x Iceberg:云原生湖仓分析技术揭秘与最佳实践
本文将深入探讨基于 StarRocks 和 Iceberg 构建的云原生湖仓分析技术,详细解析两者结合如何实现高效的查询性能优化。内容涵盖 StarRocks Lakehouse 架构、与 Iceberg 的性能协同、最佳实践应用以及未来的发展规划,为您提供全面的技术解读。 作者:杨关锁,北京镜舟科技研发工程师
StarRocks x Iceberg:云原生湖仓分析技术揭秘与最佳实践
|
10月前
|
人工智能 计算机视觉 异构计算
LLaVA-Med:微软推出专为临床放射学优化和报告生成的多模态模型
LLaVA-Med是微软推出的小型多模态模型,专注于高效生成高质量的胸部X光放射学报告,支持快速临床部署。
618 7
|
机器学习/深度学习 人工智能 自然语言处理
AI人工智能大模型的架构演进
随着深度学习的发展,AI大模型(Large Language Models, LLMs)在自然语言处理、计算机视觉等领域取得了革命性的进展。本文将详细探讨AI大模型的架构演进,包括从Transformer的提出到GPT、BERT、T5等模型的历史演变,并探讨这些模型的技术细节及其在现代人工智能中的核心作用。
889 8
|
人工智能
写歌词的技巧和方法基础教程:引领你走进音乐世界,妙笔生词智能写歌词软件
音乐是灵魂的语言,歌词则是承载灵魂的载体。本文介绍写歌词的基础技巧,包括寻找灵感、确定主题、构建结构和运用语言,同时推荐《妙笔生词智能写歌词软件》作为创作助手,助力你走进丰富多彩的音乐世界。
|
消息中间件 Kubernetes Kafka
实时计算 Flink版操作报错合集之在Rancher K8s部署时,TaskManager无法正常连接到其他TaskManager,该如何处理
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
|
Java
SpringBoot启动报错:Unable to start LiveReload server【已解决】
SpringBoot启动报错:Unable to start LiveReload server【已解决】
821 1
|
关系型数据库 MySQL 数据库
Docker实现MySQL主从复制
Docker实现MySQL主从复制
262 0