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 비트 int에 대해 가능한 가장 높은 값입니다. 최종 값은 가능한 가장 높은 유닉스 시간 (UNIXTIME)과 가능한 가장 긴 정수 (int) 사이의 차이이며, 18 일을 약간 넘는 초입니다. 로컬 시간대의 2037 끝에 끝납니다. 어떤 아이디어? 그것은 계산 중 하나에서 자연적인 단점입니까? 그것은 mysqld의 임의의 한도입니까?

Answer 1

일반적으로 유닉스 타임 스탬프 범위는 자세한 내용은 2037 내가 + 그리니치 표준시 02시 매우 다른 결과를 얻었다 http://en.wikipedia.org/wiki/Year_2038_problem

Answer 2

를 보라 1 월 1 일 1970 년 12 월 31 일이다. 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