Що таке Unix-мітка часу?
Unix-мітка часу — це єдине число: кількість секунд, що минули з Unix-епохи, визначеної як 00:00:00 UTC 1 січня 1970 року. Ось і все. Жодного часового поясу, жодного рядка з датою, жодних назв місяців — просто ціле число, яке збільшується на одиницю щосекунди.
Оскільки епоха є фіксованою та універсальною, мітка часу, як-от 1700000000, означає той самий момент у будь-якій точці Землі. Сервер у Токіо та ноутбук у Чикаго погодяться, що вона відповідає 14 листопада 2023 року о 22:13:20 UTC. Локальне відображення відрізняється залежно від часового поясу, але базове число ніколи не змінюється.
Одне навмисне спрощення: Unix-час ігнорує високосні секунди. Він припускає, що кожен день триває рівно 86 400 секунд, що не зовсім відповідає астрономічній реальності, але зберігає арифметику чистою. Докладніше про це нижче.
Чому інженери їх люблять
Мітки часу є всюди в програмному забезпеченні — час модифікації файлів, записи в базах даних, відповіді API, поля терміну дії JWT, рядки журналів — і не без причини:
- Це єдине значення. Одне ціле число зберігає повну дату та час. Жодного парсингу, жодної двозначності щодо
ММ/ДДпротиДД/ММ. - Вони не залежать від часового поясу. Число завжди в UTC. Ви конвертуєте в локальний час, лише коли показуєте його людині.
- Їх легко порівнювати та сортувати. Яка подія сталася раніше? Менше ціле число. Тривалість між двома подіями? Відніміть їх; відповідь у секундах.
- Вони компактно зберігаються. Одне 4- або 8-байтове ціле число проти форматованого рядка.
Ось чому так багато інфраструктури внутрішньо працює з секундами епохи, навіть коли інтерфейс показує вам зручний 2026-07-23. Якщо ви хочете переходити між цими двома представленнями, конвертер Unix-міток виконує переклад в обох напрямках.
Читання мітки: приклад
Візьмемо мітку часу 1000000000 — відому, оскільки вона переповнилася в прямому ефірі серед ентузіастів Unix.
Щоб прочитати її вручну, ви ділите секунди на більші одиниці. Приблизно 1 000 000 000 секунд — це близько 31,7 року (рік становить ~31 556 952 секунди). Додайте це до епохи 1970 року, і ви потрапите в 2001 рік. Точний момент — 09 вересня 2001 року, 01:46:40 UTC.
Ви рідко виконуєте цю арифметику вручну — кожна мова має вбудовану функцію. У Python:
```python from datetime import datetime, timezone datetime.fromtimestamp(1000000000, tz=timezone.utc)
2001-09-09 01:46:40+00:00
```
Ключовий момент: конвертація завжди прив'язана до UTC. Функція перетворює необроблену кількість секунд на календарну дату, рухаючись вперед від епохи. Якщо замість цього вам потрібен локальний час, ви застосовуєте зсув часового поясу після конвертації в UTC — сама мітка часу не містить інформації про часовий пояс.
Проблема 2038 року
Ось де історія стає цікавою — і де багато, здавалося б, добре побудованих систем мають всередині цокання годинника.
Протягом десятиліть стандартний тип C, який використовувався для зберігання Unix-часу, time_t, зазвичай був 32-бітним цілим числом зі знаком. 32-бітне ціле число зі знаком може представляти значення від −2 147 483 648 до 2 147 483 647. Ця верхня межа і є проблемою.
Відраховуючи секунди від епохи 1970 року, значення 2 147 483 647 досягається о 03:14:07 UTC 19 січня 2038 року. Через одну секунду лічильник має стати 2 147 483 648 — але це число не поміщається в 32-бітне ціле число зі знаком. Замість того, щоб продовжувати зростання, біти переповнюються і загортаються до найбільш від'ємного значення, −2 147 483 648.
Від'ємна мітка часу інтерпретується як час до епохи. Отже, годинник не просто зупиняється — він стрибає назад до 13 грудня 1901 року. Будь-яка система, яка довіряла своєму 32-бітному time_t, раптово вважає, що зараз початок двадцятого століття.
Це часто називають помилкою Y2K38 або Unix-міленіумним багом, і структурно це той самий тип переповнення фіксованої ширини, який спричинив паніку навколо проблеми 2000 року — просто далі в часі та вкорінений у межах двійкових цілих чисел, а не двозначних років.
Де це насправді кусає
Сучасні 64-бітні настільні комп'ютери та сервери були значною мірою виправлені роки тому. Ризик зосереджений у місцях, які важко оновити:
- Вбудовані та промислові системи. Роутери, контролери, медичні пристрої, автомобільні ЕБУ та IoT-обладнання, які постачалися з 32-бітним
time_tі можуть працювати без змін 20+ років. Багато пристроїв, розгорнутих сьогодні, все ще будуть в експлуатації у 2038 році. - Застарілий код C. Програми, скомпільовані зі старим визначенням
time_t, особливо коли тип потрапив у формати на диску або мережеві протоколи. - Старі бази даних і файлові системи. Формати зберігання, які пакували мітки часу в 32-бітні поля. Деякі старі системи вже демонструють симптоми під час обробки дат у далекому майбутньому — подумайте про 20-річну іпотеку або термін дії сертифіката, який сягає 2038 року.
Режим збою не завжди є драматичним крахом. Іноді це тонка помилка обчислення дати: прострочений токен, який читається як дійсний, порядок сортування, який інвертується, заплановане завдання, яке запускається у 1901 році.
Виправлення: 64-бітний час
Засіб є простим у принципі — розширити time_t до 64 біт. 64-бітне ціле число зі знаком може відраховувати секунди далеко за будь-який практичний горизонт: точка переповнення знаходиться приблизно через 292 мільярди років у майбутньому, що значно перевищує очікуваний час життя Сонця.
Більшість сучасних операційних систем вже зробили цей крок. 64-бітний Linux використовує 64-бітний time_t; навіть 32-бітний Linux отримав підтримку 64-бітного часу в ядрі та glibc в останні роки. Складність полягає не в самому виправленні — вона полягає в пошуку та перезбиранні кожної частини прошивки, кожного збереженого формату та кожного стороннього бінарного файлу, який все ще передбачає 32 біти. Ця аудиторська робота і є справжнім проектом 2038 року.
Як вписуються високосні секунди
Астрономічний час і атомний час трохи розходяться, тому офіційний UTC час від часу вставляє високосну секунду, щоб синхронізувати годинники з обертанням Землі. Unix-час, за задумом, вдає, що їх не існує — він жорстко кодує 86 400 секунд на день.
Коли відбувається високосна секунда, системи зазвичай "розмазують" її — розподіляючи додаткову секунду протягом певного проміжку часу (Google популяризував 24-годинне розмазування), щоб жоден годинник ніколи не показував неможливе 23:59:60. Підсумок: Unix-мітки часу залишаються плавними та монотонними, ціною невеликої частки секунди відхилення від строгого UTC під час розмазування. Для практично всього програмного забезпечення це саме той компроміс, який вам потрібен. Переповнення 2038 року — це проблема ширини цілого числа; високосні секунди — це окрема, набагато менша визначеннєва химерність — не плутайте їх.
Ключові висновки
- Unix-мітка часу — це секунди з 00:00:00 UTC 1 січня 1970 року, високосні секунди ігноруються.
- Це єдине, незалежне від часового поясу ціле число — легко зберігати, порівнювати та сортувати.
- Конвертація завжди відносна до UTC; локальний час застосовується після.
- 32-бітний
time_tзі знаком переповнюється о 03:14:07 UTC 19 січня 2038 року, загортаючись до від'ємного значення та стрибаючи до 1901 року. - Виправлення — 64-бітний
time_t; зусилля полягають в аудиті вбудованих та застарілих систем.
Хочете побачити це в дії? Вставте будь-яке значення епохи в конвертер Unix-міток, щоб прочитати його як людську дату — або піти іншим шляхом і перетворити дату на її мітку часу.
Поширені запитання
Чи є Unix-мітка часу в секундах чи мілісекундах?
Класичний Unix-час — у секундах. Однак JavaScript та багато веб-API використовують мілісекунди з моменту епохи, тому значення, як-от 1700000000000, у 1000 разів більше. Швидка підказка: мітка часу на основі секунд для недавньої дати має 10 цифр; мілісекундна — 13. Якщо сумніваєтеся, перевірте порядок величини перед конвертацією.
Чи призведе проблема 2038 року до збою мого телефону чи ноутбука?
Майже напевно ні. Сучасні 64-бітні операційні системи вже використовують 64-бітний time_t, що відсуває переповнення на мільярди років. Реальна загроза — у довгоживучих вбудованих пристроях та старому програмному забезпеченні, яке все ще покладається на 32-бітний час і може не бути оновлене до 2038 року.
Чи може Unix-мітка часу бути від'ємною?
Так. Від'ємні значення представляють моменти до епохи 1970 року — наприклад, -1 — це 31 грудня 1969 року, 23:59:59 UTC. Саме це і створює 32-бітне переповнення у 2038 році, тому годинник ніби стрибає назад до 1901 року.
Чому Unix-час ігнорує високосні секунди?
Щоб зберегти математику простою та передбачуваною. Вважаючи кожен день рівно 86 400 секунд, тривалості є просто відніманням, а мітки часу залишаються монотонними. Невелика невідповідність з астрономічним UTC вирішується "розмазуванням" високосної секунди, що майже всі програми вважають за краще, ніж мати справу з крайнім випадком 23:59:60.
Як конвертувати мітку часу без написання коду?
Використовуйте онлайн-інструмент. конвертер Unix-міток приймає значення епохи та миттєво показує відповідну дату та час у UTC та локальному часі, а також конвертує календарні дати назад у мітки часу.