Конвертер Unix Timestamp

Конвертуйте будь-яку позначку часу Unix у зрозумілу людині дату та час.

Наш конвертер:

• автоматично визначає секунди (10 цифр) та мілісекунди (13 цифр)
• показує UTC та місцевий час
• відображає кілька форматів, зокрема ISO 8601 та RFC 2822

Конвертуйте будь-яку дату та час у відповідну позначку часу Unix.

Виберіть дату, оберіть свій часовий пояс і отримайте час епохи в секундах та мілісекундах.

Ідеально підходить для:

• розробки API
• запитів до баз даних
• налагодження проблем, пов'язаних з часом

Час Unix — це система відстеження певної точки в часі як кількості секунд, що минули з моменту епохи Unix, визначеної як 00:00:00 UTC 1 січня 1970 року. IEEE та The Open Group закріпили це у стандарті POSIX (IEEE Std 1003.1), де він формально називається «Секунди з початку епохи».

Ключова тонкість, задокументована POSIX, полягає в тому, що час Unix навмисно ігнорує високосні секунди, тому кожен день розглядається рівно як 86 400 секунд. Оскільки значення є єдиним цілим числом, незалежним від часових поясів, воно є однозначним у різних системах.

Зберігання часу у вигляді цілого числа, як зазначає документація MDN Web Docs для об'єкта Date у JavaScript, робить арифметичні операції та порівняння елементарними порівняно з парсингом відформатованих рядків дат.

10-значна позначка часу Unix рахує секунди з моменту епохи, тоді як 13-значна позначка часу рахує мілісекунди, і їх змішування є найпоширенішою помилкою конвертації.

Згідно з MDN Web Docs, функції JavaScript Date.now() та getTime() повертають мілісекунди, тому 1700000000000 є дійсним значенням для JS. Натомість функції POSIX C, такі як time() та time.time() у Python із відсіканням, а також більшість баз даних SQL та команда Bash date +%s, працюють в секундах (1700000000).

Щоб конвертувати їх одне в одне, помножте секунди на 1 000 або розділіть мілісекунди на 1 000.

Наш конвертер автоматично визначає одиницю вимірювання за кількістю цифр, але під час написання коду ви завжди повинні перевіряти, яку одиницю очікує ваша мова або API, щоб уникнути дат, які потрапляють у 1970 рік або на тисячі років у майбутнє.

Ви можете згенерувати поточну позначку часу Unix за допомогою одного виклику практично в кожній мові програмування.

• У JavaScript MDN Web Docs рекомендує Math.floor(Date.now() / 1000) для секунд або Date.now() для мілісекунд.
• У Python time.time() повертає числа з плаваючою комою для секунд з початку епохи, що відповідає функції бібліотеки C time(), визначеній стандартом POSIX.
• У командному рядку date +%s у GNU coreutils виводить поточну позначку часу з точністю до секунди, тоді як PHP використовує time(), а Go — time.Now().Unix().
• Рушії SQL надають такі функції, як UNIX_TIMESTAMP() у MySQL та EXTRACT(EPOCH FROM now()) у PostgreSQL.

Усі вони посилаються на одне й те саме джерело 1970 року UTC, тому значення є безпосередньо взаємозамінними, щойно ви нормалізуєте одиницю вимірювання (секунди проти мілісекунд).

Використовуйте позначку часу Unix для зберігання та арифметичних обчислень, а ISO 8601 — для зручного для читання людиною обміну та логів.

ISO 8601 — це міжнародний стандарт представлення дат і часу у вигляді рядків на зразок 2023-11-14T22:13:20Z, де велика літера T відокремлює дату від часу, а кінцева літера Z позначає UTC (час зулу). Ці літери чутливі до регістру, тому, якщо ви впорядковуєте рядки, скопійовані з джерел із різним регістром, швидка перевірка через конвертер регістру допоможе зберегти їх придатними для парсингу. Стандарт IETF RFC 3339 описує ISO 8601 для використання в Інтернеті, і саме його приймає більшість JSON API для полів дат, оскільки сам JSON (RFC 8259) не має власного типу дати.

Ціле число Unix є більш компактним і нейтральним до локалі, але не описує себе самостійно, тоді як рядок ISO 8601 є миттєво зрозумілим. Багато систем зберігають ціле число внутрішньо та серіалізують його в ISO 8601 на межі API, щоб отримати переваги обох варіантів.

Позначка часу Unix не має часового поясу, оскільки вона завжди посилається на єдину мить, виміряну від епохи в UTC. Часові пояси мають значення лише тоді, коли ви візуалізуєте цю мить як календарну дату для користувача.

База даних часових поясів IANA (tz database) є авторитетним джерелом, яке операційні системи та мови використовують для зіставлення моменту часу з місцевим часом, включаючи історичні правила переходу на літній час.

Найкраща практика, яку підтримують MDN Web Docs та незліченні інженерні посібники, полягає в тому, щоб зберігати та передавати позначки часу в UTC і конвертувати їх у місцевий пояс глядача лише під час відображення. Це усуває невизначеність щодо переходів на літній час і робить міжрегіональні порівняння надійними та відтворюваними.

Проблема 2038 року — це момент, коли 32-розрядні цілі числа зі знаком, що зберігають час Unix, переповняться, що станеться о 03:14:07 UTC 19 січня 2038 року.

Значення зі знаком на 32 біти досягає максимуму в 2 147 483 647 секунд; на одну секунду пізніше воно перетворюється на велике від'ємне число, яке непідготовлений код інтерпретує як грудень 1901 року. Це нагадує історичні побоювання щодо проблеми 2000 року, але базується на фіксованій ширині типу C time_t на застарілих платформах.

Сучасні операційні системи та мови програмування значною мірою перейшли на 64-розрядний час time_t, що відсуває переповнення приблизно на 292 мільярди років у майбутнє. Вбудовані системи та старі формати файлів залишаються основними зонами ризику, які розробникам варто перевірити.

Мітки часу Unix є основою обробки часу в серверних системах, логах та API, оскільки вони сортуються, порівнюються та обчислюються як звичайні цілі числа.

Бази даних зберігають стовпчики created_at та updated_at як значення епохи або похідні від них типи міток часу, а кеш-шари використовують мітки часу закінчення терміну дії для інвалідації записів. Токени безпеки також покладаються на них: стандарт JWT, RFC 7519, визначає поля exp (термін дії) та iat (час видачі) як значення NumericDate, які фактично є секундами з моменту початку епохи Unix.

Розподілені логи та потоки подій використовують мітки часу для встановлення послідовності, а ліміти запитів порівнюють поточну епоху зі збереженими вікнами. Їхня незалежність від мови програмування робить їх ідеальними для передачі часу між різними сервісами.

Від'ємні мітки часу Unix представляють моменти до епохи, тому -86400 відповідає 31 грудня 1969 року о 00:00:00 UTC. Визначення POSIX дозволяє відлік секунд бути від'ємним, і такі мови, як JavaScript, дотримуються цього: документація MDN Web Docs зазначає, що об'єкт Date приймає від'ємні значення мілісекунд для вираження дат до 1970 року.

Це корисно для історичних даних, дат народження або архівних записів.

Однак майте на увазі, що деякі старі системи, бази даних та 32-бітні інструменти розглядають час Unix як беззнаковий або відхиляють від'ємні вхідні дані, мовчки округлюючи значення до епохи або видаючи помилку. Під час обробки історичних дат переконайтеся, що кожен шар вашого стеку, від типу стовпчика бази даних до клієнтської бібліотеки, підтримує мітки часу зі знаком.

• Найчастіша помилка полягає в тому, щоб плутати секунди з мілісекундами, що створює дати на десятиліття вперед або застрягає в 1970 році. Завжди перевіряйте одиницю виміру вашого джерела перед конвертацією, оскільки JavaScript виводить мілісекунди, тоді як більшість бекендів виводять секунди.
• Другий підводний камінь — це припущення, що мітка часу містить часовий пояс; це не так, тому подвійне застосування локального зсуву дає невірний час на годиннику.
• Інші помилки включають ігнорування обмеження 2038 року на 32-бітних полях і очікування, що час Unix враховуватиме високосні секунди, які POSIX явно виключає.
• Нарешті, уникайте ручного розбору відформатованих рядків дат; використовуйте стандартні бібліотеки та віддавайте перевагу ISO 8601 (RFC 3339) для обміну даними, як радить MDN Web Docs, щоб уникнути неоднозначних форматів на кшталт ММ/ДД проти ДД/ММ.