6 
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吗？

4

2 回答 2

5

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

于 2011-01-21T18:22:11.560 回答
0

我在 GMT+0200 得到了非常不同的结果。i686 和 x86_64 的结果相同。

大概 2038-01-01 UTC 是不允许的。

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 |
+---------------------------+---------------------------+---------------+----------------------------+ 
| 2038-01-01 01:59:59       | 2038-01-01 02:00:00       |    2147483647 |                    -1566850 |  
+---------------------------+---------------------------+---------------+------------------- ---------+
1 row in set (0.00 sec)

mysql> \s
--------------
mysql  Ver 14.12 Distrib 5.0.77, for redhat-linux-gnu (i686) using readline 5.1
于 2011-01-21T18:26:48.097 回答