Стаття
Unix-часові мітки та cron-вирази: пояснення
Unix-часова мітка - це просто ціле число. Cron-вираз - це просто п'ять полів. Обидва постійно зустрічаються у серверній роботі, і обидва стають каменем спотикання передбачуваними способами: перший через часові пояси, другий через одиниці.
Що таке Unix-часова мітка
Unix-часова мітка рахує кількість секунд, що минули з 1970-01-01 00:00:00 UTC, точки відліку, відомої як Unix epoch. Це визначення має два важливі наслідки. По-перше, відлік ведеться в UTC: у самому числі немає вбудованого часового поясу. 1718400000 означає той самий момент скрізь на Землі незалежно від місцезнаходження машини, що його зберігає. По-друге, epoch визначена в секундах, а не в будь-яких інших одиницях. Значення на кшталт 1718400000 завжди є секундами від опівночі 1 січня 1970 року UTC, якщо система або протокол явно не зробили іншого вибору. Часові мітки є вільними від часового поясу за своєю природою, що робить їх корисними для журналювання, баз даних та міжсистемної комунікації, де годинники в різних регіонах мають однозначно посилатися на один момент.
Секунди, мілісекунди та проблема 2038 року
Багато сучасних середовищ виконання та API використовують мілісекунди замість секунд. Date.now() JavaScript повертає мілісекунди, тому 1718400000000 є тим самим моментом, що й значення з точністю до секунди 1718400000. Коли ви отримуєте незнайому часову мітку, розмір говорить вам про одиниці: 10-значне число майже завжди є секундами; 13-значне число майже завжди є мілісекундами. Проблема 2038 виникає з іншого вибору: зберігання часової мітки з точністю до секунди в знаковому 32-bit цілому числі. Максимальне значення знакового 32-bit цілого числа дорівнює 2147483647, що відповідає 2038-01-19 03:14:07 UTC. Після цієї секунди лічильник переповнюється до великого від'ємного числа і дата відкочується до 1901 на системах, що не обробляють межу. Виправлення полягає в використанні 64-бітного сховища. Більшість сучасних операційних систем та баз даних вже так роблять, але вбудовані системи, мережеві пристрої та старі формати файлів, у яких ширина поля зафіксована десятиліття тому, залишаються під загрозою.
Перетворення epoch на дату для людини: крок часового поясу
Перетворення значення epoch на читабельну дату вимагає двох кроків: отримання компонентів дати UTC з цілого числа, потім застосування зміщення UTC для отримання місцевого часу. Часова мітка сама по собі є UTC. Коли ви запитуєте, яку дату представляє 1718325000, правильна відповідь - 2024-06-14 о 00:30 в UTC. У Нью-Йорку (UTC-4 влітку) та сама секунда припадає на 2024-06-13 о 20:30 напередодні ввечері: змінюється дата, а не лише година. Це крок, що дає неправильні результати при пропуску: розробник записує необроблену часову мітку в UTC, інструмент звітності відображає її в місцевому часі без перетворення, і дата виглядає зміщеною на кілька годин або на цілий день. Інструмент timestamp-converter на Sunasty обробляє це явно: ви вводите значення epoch, і він показує дату та час UTC поруч із власними локальними датою та часом вашого пристрою, тож перетин межі доби, як у цьому прикладі, видно одразу. Перетворення виконується повністю в браузері і нічого, що ви вставляєте, нікуди не надсилається.
Синтаксис cron: п'ять полів, діапазони, кроки та списки
Cron-вираз планує повторювані завдання на Unix-подібних системах. Стандартний синтаксис має п'ять полів, розділених пробілами: хвилини (0-59), години (0-23), день місяця (1-31), місяць (1-12), день тижня (0-7, де 0 і 7 обидва представляють неділю). Зірочка (*) у полі означає «кожне допустиме значення». Вираз 30 8 * * 1-5 запускається о 08:30 з понеділка по п'ятницю. Діапазони використовують дефіс: 1-5 охоплює значення 1, 2, 3, 4, 5. Списки використовують коми: 1,15 означає 1-ше та 15-те. Кроки використовують косу риску: */15 у полі хвилин означає кожні 15 хвилин (0, 15, 30, 45). Ці комбінатори можуть з'являтися разом: 0-30/10 означає 0, 10, 20, 30. Одна річ, якої у cron немає, - це поле часового поясу. Демон читає годинник машини, на якій він запущений, що налаштований на місцевий часовий пояс сервера. Якщо сервер працює в UTC, але розробник очікує місцевий час, розклад запускається в неправильну годинникову годину. Практичне правило: розглядати cron-розклади як вирази місцевого часу сервера та документувати часовий пояс сервера поряд із cron-рядком.
Використання timestamp-converter локально
Конвертер часових міток на Sunasty конвертує в обох напрямках: epoch на дату для людини та дата для людини назад на epoch. Ви можете ввести значення з точністю до секунди або мілісекунди; інструмент визначає одиниці за розміром. Він показує результат в UTC та у власному місцевому часовому поясі вашого пристрою поруч, разом із необробленими значеннями в секундах і мілісекундах, готовими для копіювання. Кнопка «Зараз» одним кліком заповнює поточну часову мітку, що є швидким способом дізнатися поточний Unix-час без відкриття терміналу. Окремого вибору часового поясу немає: колонка місцевого часу завжди відображає той часовий пояс, який наразі встановлено у вашому браузері. Все це працює в браузері. Значення, яке ви вставляєте у поле, зчитується клієнтським JavaScript і ніколи не залишає пристрій.
Інструменти з цієї статті
- Конвертер позначок часуКонвертуйте позначки часу Unix epoch у зрозумілі дати (UTC + локальний) і назад. Автоматично визначає секунди чи мілісекунди.
- Різниця між датамиПідрахуйте дні, тижні, місяці та роки між двома датами, повністю у вашому браузері, нічого не завантажується на сервер.
- Розбірник виразів cronРозберіть вираз cron і перегляньте його наступні запуски. Приватно, у браузері.
Поширені запитання
Чому JavaScript використовує мілісекунди замість секунд?
Об'єкт Date в JavaScript був розроблений для роботи з точністю менше секунди від початку, і мілісекунди дають у тисячу разів більшу роздільну здатність, ніж секунди, не вимагаючи десяткової крапки. Компроміс полягає в тому, що значення більші, тому Date.now() видає 13-значне число, тоді як більшість серверних часових міток мають 10 цифр.
Чи повинен кожен сервер, що запускає cron, бути в UTC?
Ні, але запуск серверів в UTC є поширеною практикою саме тому, що це усуває неоднозначність. Коли сервер знаходиться в UTC, cron-вираз на кшталт 0 2 * * * означає 02:00 UTC, і цей час є стабільним цілий рік. На сервері в зоні з літнім часом те саме завдання запускається в різний момент UTC влітку та взимку, і при переключенні годинника воно може запуститися двічі або пропустити один раз.
Який безпечний тип сховища для часових міток після 2038 року?
Знакове 64-бітне ціле число зберігає часові мітки з точністю до секунди до 292277026596 року, що набагато перевищує будь-яке практичне занепокоєння. Більшість сучасних баз даних за замовчуванням зберігають часові мітки як 64-бітні значення. Якщо ви працюєте зі застарілою схемою або бінарним форматом файлу, що використовує 32-bit поля, міграція на 64-бітне сховище до межі 2038 є правильним виправленням.