为什么MySQL unix时间不能超过32位无符号整数限制？ [英] Why does MySQL unix time stop short of the 32 bit unsigned integer limit?

问题描述

mysql> SELECT FROM_UNIXTIME(2145916799), FROM_UNIXTIME(2145916800), POW(2,32-1)-1, 2145916799 - POW(2,32-1)-1;
+---------------------------+---------------------------+---------------+----------------------------+
| FROM_UNIXTIME(2145916799) | FROM_UNIXTIME(2145916800) | POW(2,32-1)-1 | 2145916799 - POW(2,32-1)-1 |
+---------------------------+---------------------------+---------------+----------------------------+
| 2037-12-31 18:59:59       | NULL                      |    2147483647 |                   -1566850 | 
+---------------------------+---------------------------+---------------+----------------------------+
1 row in set (0.00 sec)

mysql> 

第一个字段是我可以给 FROM_UNIXTIME的最高值。下一个字段是该值加上一个返回 NULL 的字段。第三个字段是无符号32位int的最高可能值。最终值是最高可能的UNIXTIME和最高可能的int之间的差异，这是一个超过18天的秒。它似乎在本地时区的 2037 结束时停止。有什么想法吗？在其中一项计算中，这是一个自然的突破点吗？这只是 mysqld 中的任意限制吗？

The first field is the highest possible value I can give to FROM_UNIXTIME. The next field is that value plus one which returns NULL. The third field is the highest possible value for an unsigned 32 bit int. The final value is the difference between the highest possible UNIXTIME and the highest possible int which is a little over 18 days worth of seconds. It appears that it stops at the end of 2037 in the local timezone. Any ideas why? Is that a natural breaking point in one of the calculations? Is that just an arbitrary limit in mysqld?

推荐答案

通常是unix时间戳范围是从1970年1月1日到2037年12月31日
更多信息，请查看 http：// en.wikipedia.org/wiki/Year_2038_problem

normally unix timestamp range is from January 1st 1970 to December 31st 2037 for more information have a look at http://en.wikipedia.org/wiki/Year_2038_problem

这篇关于为什么MySQL unix时间不能超过32位无符号整数限制？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！