负数 mysql 时间戳_【mysql】负数时间戳日期转换问题

在MySQL中,使用FROM_UNIXTIME处理负时间戳时出现错误,因为负时间戳对应的历史日期转换存在差异。文章探讨了1927年时间跳跃现象,即在某些时间点,时间被调整了5分52秒。这个问题可能导致转换结果与实际日期相差几分钟。一些在线转换工具能够正确处理这种情况,但具体实现未明确。文章提到了可能与上海与北京时间校准有关的历史原因,但也指出此解释并不严谨。解决方案包括在编程时考虑时间跳跃因素。
摘要由CSDN通过智能技术生成

使用 mysql 提取数据时,遇到一个问题:负时间戳无法通过FROM_UNIXTIME 方法转化成正常的日期:

FROM_UNIXTIME(-2641363543)

Null

这个时间戳对应的正确的日期其实是: 1886-04-20 00:00:00,我搜索了一下,有人建议采用加减的方式计算负值时间戳的日期:

DATE_ADD(FROM_UNIXTIME(0), INTERVAL -2641363543 SECOND)

1886-04-19 23:54:17

但转化出来的,和正确值有几分钟差距.我找了一些网页端的时间戳转换工具,他们都可以转换成正确值,我就不知道是怎么实现的,另外上面这种转化逻辑的问题是在哪呢?

回答

0代表是1970年1月1日0时0分0秒

可得:1969年12月31日23时59分0秒的值应该是:-60

也就是说:以0秒结尾的时间,时间戳必然也以0结尾。

而-2641363543以3结尾,必然不对应

看完评论后,又找了下相关的信息,简单总结两句:

先看在线时间转换两张图:

0c9c5dfca3d09f914956e5ad1e9e6c6e.png

d55f6bfc89f263e2ac9af605991e9293.png

有点意思,两个时间戳差1秒,但是转换后的时间差了几分钟。

相关的资料显示: 在1927年12月31日23:59:59时,往后面的一秒应该是1928年1月1日 0:0:0,但是这个时间被往后调整了5分52秒,而成了,1927年12月31日的,23:54:08,于是,完成了352秒的穿越。

相关资料也显示,在某些(JAVA8并不适用)的JAVA版本中,两个相关1秒的时间实际上却在时间戳上相差了353秒。

但无论是对1927年进行了调整还是对1900年进行了调整,可以确认的是在历史上这352秒的穿越是存在的。如果你使用编程语言考虑到了这个穿越的因素,则会出现你遇到的上述问题。

至于为什么要如此调整,有人猜原因是:为了将上海的时间与北京时间相统一,所以上海时间与北京时间差的就是这352秒。

但这个好像并占不住脚,北京与上海的经度差在5度,每1度差4分钟,5度应该是20分钟,大概为1200秒。

时区问题,谷歌浏览器时间是1901年前的时区按+805而不是+800,因此时间戳-2641363543对应 1886-04-20 00:00:00 的时区是+805。

c11d6ee126e5389d685ab85eb4ff64c1.png

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值