【mysql】负数时间戳日期转换问题
使用 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
结尾,必然不对应
看完评论后,又找了下相关的信息,简单总结两句:
先看在线时间转换两张图:
有点意思,两个时间戳差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。
以上是 【mysql】负数时间戳日期转换问题 的全部内容, 来源链接: utcz.com/a/74818.html