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です。3番目のフィールドは、符号なし32ビット整数の可能な最大値です。最終的な値は、可能な限り最高のUNIXTIMEと、可能な限り最高のintの差であり、18日強の秒に相当します。2037ローカルタイムゾーンの終わりで停止しているようです。なぜ何かアイデアはありますか？それは計算の1つにおける自然な限界点ですか？それはただの恣意的な制限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-01UTCは許可されませんでした。

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 に答える