Защо времето на MySQL unix не достига ограничението за 32-битово цяло число без знак?

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. Третото поле е най-високата възможна стойност за unsigned 32 bit int. Крайната стойност е разликата между най-високото възможно UNIXTIME и най-високото възможно int, което е малко над 18 дни на стойност секунди. Изглежда, че спира в края на 2037 в местната часова зона. Някакви идеи защо? Това естествена точка на прекъсване ли е в някое от изчисленията? Това само произволно ограничение в mysqld ли е?


mysql timestamp unix-timestamp int data-storage
person 700 Software    schedule 21.01.2011    source източник
comment
Добър въпрос. Може да има нещо общо с часовите зони.   -  person Antti Rytsölä    schedule 21.01.2011
comment
Заобиколно решение за получаване на форматирани дати след 2038-01-19 03:14:07 от времеви отпечатъци на unix е обяснено на stackoverflow.com/a/40899947/320594   -  person Jaime Hablutzel    schedule 08.06.2019

Отговори (2)


arrow_upward
5
arrow_downward

обикновено времевият диапазон на unix е от 1 януари 1970 г. до 31 декември 2037 г. за повече информация вижте http://en.wikipedia.org/wiki/Year_2038_problem

person shankhan    schedule 21.01.2011

arrow_upward
0
arrow_downward

Получих много различни резултати в 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
person Antti Rytsölä    schedule 21.01.2011
comment
Аз съм в американското източно време, така че това би обяснило разликата. - person 700 Software; 21.01.2011