负数时间戳日期转换问题

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

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

阅读 138
评论
    2 个回答
    • 1.3k

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

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

        撰写回答

        登录后参与交流、获取后续更新提醒

        相似问题
        推荐文章