MySQL from_unixtime 2038-01-19 之后?
MySQL from_unixtime after 2038-01-19?
我们将日期存储为 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 时间戳。然而,MySQL 方法 from_unixtime
不支持任何大于 2147483647
的值的转换,因为它是整数类型限制:
SELECT FROM_UNIXTIME(2147483647); //2038-01-19 04:14:07
SELECT FROM_UNIXTIME(2147483648); //null
MySQL 服务器本身是 64 位的,但是是 ofc。 FROM_UNIXTIME
需要接受 long as 参数。
我现在找不到合适的替代品,有什么提示吗?
我们当然可以。将时间戳加载为 Long 并在应用程序中处理它 - 但是对于 lazylaoding 我们还需要能够在查询期间正确转换它。
解决方法可能是使用 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
...
如果有的话,应该尽量减少对性能的影响。
我们将日期存储为 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 时间戳。然而,MySQL 方法 from_unixtime
不支持任何大于 2147483647
的值的转换,因为它是整数类型限制:
SELECT FROM_UNIXTIME(2147483647); //2038-01-19 04:14:07
SELECT FROM_UNIXTIME(2147483648); //null
MySQL 服务器本身是 64 位的,但是是 ofc。 FROM_UNIXTIME
需要接受 long as 参数。
我现在找不到合适的替代品,有什么提示吗?
我们当然可以。将时间戳加载为 Long 并在应用程序中处理它 - 但是对于 lazylaoding 我们还需要能够在查询期间正确转换它。
解决方法可能是使用 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
...
如果有的话,应该尽量减少对性能的影响。