负数时间戳日期转换问题

Question

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

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

Answer 1

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秒。

Answer 2

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