Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
3.8k views
in Technique[技术] by (71.8m points)

负数时间戳日期转换问题

使用 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

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


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Answer

0 votes
by (71.8m points)

0代表是1970年1月1日0时0分0秒
可得:1969年12月31日23时59分0秒的值应该是:-60
也就是说:以0秒结尾的时间,时间戳必然也以0结尾。
-26413635433结尾,必然不对应


看完评论后,又找了下相关的信息,简单总结两句:
先看在线时间转换两张图:

image.png
image.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秒。


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

2.1m questions

2.1m answers

60 comments

57.0k users

...