2038 年发行 - 64 位(Linux 操作系统、php、mysql) [英] year 2038 issue - 64 bit (Linux OS, php, mysql)

问题描述

select unix_timestamp('2038-01-19') 返回 2147472000

while select unix_timestamp('2038-01-20') 返回 0

我检查了2038年的问题.

我的 linux 操作系统是 64 位，安装的 mysql 版本也是 64 位.现在这个问题的解决方案是什么?

My linux OS is 64 bit and installed mysql version is also 64 bits. What is the solution to this problem now?

mysql --version 返回 mysql Ver 14.14 Distrib 5.5.47，用于 Linux (x86_64) 使用 readline 5.1
PHP 也是 64 位.

mysql --version returns mysql Ver 14.14 Distrib 5.5.47, for Linux (x86_64) using readline 5.1
Php is 64 bit too.

也试过 BigInt，没用(返回同样的东西).

Tried BigInt too, didn't work (returns the same thing).

推荐答案

简单地说，对于 MySQL，将日期存储为 DATETIME 而不是 TIMESTAMP>.

Simply put, for MySQL, store dates as DATETIME rather than TIMESTAMP.

TIMESTAMP 是 4 个字节，因此没有物理空间可以存储比 1970-1-1 到 2038-01-19 以来更多的秒数...

TIMESTAMP is 4 bytes, so there is no physical room to store more seconds than since 1970-1-1 to 2038-01-19...

DATETIME 的范围是 1000-1-1 到 9999-12-31...

DATETIME, instead, has a range of 1000-1-1 to 9999-12-31...

另见这个完整问题/答案:PHP &mySQL:2038 年错误:它是什么?如何解决?

更新:我看到的一种可能的替代方法是，如果您无法更改字段类型，则以不同的方式解释您的时间戳...
我的意思是:如果您的应用程序将跟踪的 first 事件是 - 例如 - 2000-1-1，您可以在后端(或在存储过程中)实现过滤器inside 数据库)，在读取时将 (2000-1-1 - 1970-1-1) 秒添加到您的时间戳中，然后减去阅读时的数量相同......这应该会给你30年的生存"......

UPDATE: One possible alternative I see, if you CAN'T change your fields types, is to interpet your timestamps differently...
I mean: if the first event your application will keep track of is - say - 2000-1-1, you could implement a filter on backend (or in a stored procedure inside the database), to add (2000-1-1 - 1970-1-1) seconds to your timestamps when reading, and subtract the same amount when reading... This should give you 30 more years of 'survival'...

这篇关于2038 年发行 - 64 位(Linux 操作系统、php、mysql)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！