爲什麼MySQL的unix時間停止短於32位無符號整數限制？

Question

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位整數的最高可能值。最終的值是最高可能的UNIXTIME和最高可能的int之間的差值，這個值稍微超過18天。它似乎停在當地時區2037的末尾。任何想法爲什麼？這是計算中的一個自然突破點嗎？這只是mysqld的任意限制嗎？

Answer 1

通常Unix時間戳的範圍是從1970年1月1日至2037年12月31日 更多信息，看看http://en.wikipedia.org/wiki/Year_2038_problem

Answer 2

我在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