Pull to refresh

Апокалипсис грядёт

MySQL
Есть такая проблема — в 2038м году количество секунд с начала эпохи Unix Time перевалит за величину signed int и исчезнет. Это как проблема 2000 года, только намного сложнее, потому что для неё нужно менять типы данных.

Так вот… в MySQL уже четырнадцать с половиной лет висит просьба починить функции UNIX_TIMESTAMP и FROM_UNIXTIME, которые не могут обрабатывать даты после 19 января 2038го. Это функции конвертации даты в Unixtime и наоборот.

Проверить это достаточно просто: попробуйте вот этот запрос.

select unix_timestamp('2038-01-20');

В 2017-м добрый человек попытался это исправить, но патч так и не приняли. Проблемы с часовыми поясами и поддержкой 32-битных систем.

Переходить на MariaDB тоже не вариант: там этот баг уже закрыт как слишком сложный.

Апокалипсис грядёт и нам остаётся только молиться… на этих разработчиков.

P.S. Теперь серьёзно: в документации есть предупреждение, что тип TIMESTAMP превращается в тыкву после 2038-го. А вот о функциях конвертации времени никто не предупреждал. Выходит, что все Unix и многие языки программирования уже перешли на 64-битные метки времени, и только функции MySQL перестанут понимать Unixtime безо всякой видимой причины.
Tags:2038mysqlmariadbлень
Hubs: MySQL
Total votes 82: ↑74 and ↓8 +66
Views83.9K
Senior Node.js Developer
from 2,000 to 4,500 $Local ExpressЕреванRemote job
Golang Developer
from 180,000 to 300,000 ₽SOAXRemote job
Senior PHP разработчик (Symfony) Рига
from 2,500 to 4,000 €Digital LineРигаRemote job
Node.js Developer
from 150,000 to 200,000 ₽BotHelpRemote job
Senior/Middle php developer
from 130,000 to 250,000 ₽Globosphere RussiaМоскваRemote job