Конвертер Unix-времени

Считаем цифры

Единственная по-настоящему хитрая часть чтения метки времени — определить её единицу, и порядок величины всё решает. На практике неоднозначности нет: для любых дат, с которыми реально работают, диапазоны не пересекаются.

Ошибка здесь — это промах в тысячу раз, так что результат попадает либо в начало 1970-х, либо на десятки тысяч лет вперёд. Очевидно, когда смотришь на это в упор; совершенно незаметно, когда это один столбец в таблице логов, — а кусается оно именно там.

Что на самом деле считает время Unix

Секунды с 00:00:00 UTC 1 января 1970 года в предположении, что каждые сутки длятся ровно 86 400 секунд.

Это предположение ложно. Високосные секунды вставляют раз в несколько лет, чтобы атомное время не расходилось с вращением Земли, которое постепенно замедляется. Время Unix их не отражает: системы повторяют секунду или «размазывают» её по суткам, лишь бы счёт оставался равномерным.

Следствие в том, что время Unix — не настоящий счёт прошедших с 1970 года секунд; оно отстаёт примерно на двадцать семь секунд. Для расписаний, журналов и сроков истечения это ровно правильный размен: равномерная арифметика важнее астрономической точности. А для измерения действительно прошедшего времени берите монотонные часы — настенные к тому же могут прыгнуть назад, когда их поправит NTP.

Проблема 2038 года

Знаковое 32-битное целое вмещает до 2 147 483 647, что как метка времени Unix означает 03:14:07 UTC 19 января 2038 года. Секундой позже оно переполняется в отрицательное, и дата становится декабрём 1901-го.

Всё современное использует 64 бита и годится примерно на 292 миллиарда лет. Несовременное — это встроенные прошивки, промышленные контроллеры, некоторые старые типы столбцов в СУБД и код на C, всё ещё полагающий time_t 32-битным. Больше всего рискуют системы, на которые никто не смотрит, — именно это сделало дорогой и проблему Y2K.

Какой формат использовать на самом деле

ISO 8601 в UTC — для всего, что пересекает границу между системами или читается человеком:

2026-08-27T14:30:00Z

Он однозначен, правильно сортируется как обычная строка и читается в логе в два часа ночи. Z здесь важна: без неё большинство парсеров считают время местным, и вы изобрели ошибку, которая проявляется только у пользователей из других стран.

Секунды Unix вполне годятся внутри системы — их используют утверждения exp и iat в JWT, а сравнение целых дёшево. Расплата в том, что они нечитаемы и приглашают ту самую путаницу с единицами.

Избегать стоит любого формата со смещением, но без идентификатора зоны (+01:00 не говорит, BST это или CET, а для будущих дат это важно), и всего из области 03/04/2026, что означает два разных дня в зависимости от того, по какую сторону Атлантики вы это читаете.

Хранение будущих событий

Тонкость, на которой попадаются. Для встречи в 09:00 в марте следующего года хранить UTC неверно: если до тех пор правила часовых поясов изменятся — а правительства их меняют, — встреча уедет. Будущие локальные события следует хранить как местное время плюс идентификатор зоны (Europe/London) и преобразовывать при показе по действующим на тот момент правилам. С прошедшими событиями наоборот: UTC, потому что случившееся уже неизменно.

Смежное

Утверждения exp и iat в JWT — это секунды Unix; декодер JWT переводит их за вас и отмечает истечение срока. Если вам нужно не преобразование, а расписание, разборщик cron покажет, когда оно сработает в следующий раз.