2038-01-19之后的MySQL from_unixtime？

Question

我们将日期存储为unix时间戳.为了允许用户搜索特定日期 - 基于他的时区设置,我们用于在查询中转换该时间戳,以确保搜索"2012-05-03"将找不到先前/下一个的结果一天取决于用户设置的时区.

即如果日期存储为2012-05-03 23:00 (UTC)具有适当时区偏移搜索的用户2012-05-04应找到此条目.

目前这样做是这样的:

CONVERT_TZ(FROM_UNIXTIME(`javaTimeStampColumn`/1000),'+00:00','+00:00')

在哪里 根据用户时区设置偏移量.

我们目前面临的问题是:Java成功地将一年后的日期存储2038为unix-timestamp.from_unixtime然而,MySQL方法不支持任何大于2147483647由于它的整数类型限制的值的转换:

SELECT FROM_UNIXTIME(2147483647); //2038-01-19 04:14:07

SELECT FROM_UNIXTIME(2147483648); //null

MySQL服务器本身是64位,但是ofc.FROM_UNIXTIME需要接受一个长期的论点.

我现在找不到合适的替代品,有什么提示吗？

---

我们可以.将时间戳加载为Long并在应用程序中处理它 - 但对于延迟编码,我们还需要能够在查询期间正确转换它.

Answer 1

解决方法可能是使用DATE_ADD,但我不确定它在性能方面的表现如何:

SELECT DATE_ADD(FROM_UNIXTIME(0), INTERVAL 2147483647 SECOND); //2038-01-19 04:14:07
SELECT DATE_ADD(FROM_UNIXTIME(0), INTERVAL 2147483648 SECOND); //2038-01-19 04:14:08
...
SELECT DATE_ADD(FROM_UNIXTIME(0), INTERVAL 4147483647 SECOND); //2101-06-06 07:47:27

所以现在,我正在使用

...
CASE 
  WHEN `javaTimeStampColumn` > 2147483647 THEN
    CONVERT_TZ(DATE_ADD(FROM_UNIXTIME(0), INTERVAL `javaTimeStampColumn`/1000 SECOND),'+00:00','+00:00')
  ELSE  
    CONVERT_TZ(FROM_UNIXTIME(`javaTimeStampColumn`/1000), '+00:00','+00:00')
END as ts
FROM table
...

如果有的话,应尽量减少对性能的影响.