Почему время Unix MySQL не достигает предела 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. Третье поле представляет собой максимально возможное значение для 32-битного целого числа без знака. Окончательное значение — это разница между максимально возможным значением 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 года. .wikipedia.org/wiki/Year_2038_problem

person shankhan    schedule 21.01.2011

arrow_upward
0
arrow_downward

Я получил совсем другие результаты в GMT+0200. одинаковые результаты для i686 и x86_64.

Вероятно, 01.01.2038 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