Encoders & Utilities

Unix Timestamp & Date Calculator

Конвертує Unix-epoch у читабельні дати, рахує арифметику і різниці між датами.

Про цей інструмент

Unix Timestamp & Date Calculator конвертує між integer Unix epochs і ISO 8601 / locale-formatted датами в обох напрямках. Вставте число — і він каже, чи ви годуєте секунди (10 цифр), мілісекунди (13), мікросекунди (16) чи наносекунди (19) — і рендерить відповідну дату в UTC, вашій локальній time zone і будь-якій time zone з IANA-списку. У зворотний бік — вставте дату-рядок у будь-якому типовому форматі, отримайте epoch.

Другий режим обробляє date arithmetic: додавайте або віднімайте дні, години, хвилини від базової дати; рахуйте різницю між двома датами як days/hours/minutes/seconds (або «3 роки, 2 місяці, 14 днів», якщо хочете календарні одиниці). Уся математика йде в браузері через Temporal, де доступний, і fallback-бібліотеку інакше — без time-zone-сюрпризів від DST-переходів, leap-секунд (ігноруються, як і в самому Unix time) і 2038 rollover (ми обробляємо 64-bit timestamps нативно).

Коли використовувати цей інструмент

  • Дебаг логів. Log-запис з epoch 1747459200 — вставте, побачите «17 травня 2026 04:00 UTC», готово.
  • Sanity-перевірки БД-дат. Перевірте, що значення, збережене як BIGINT ms, справді декодується в очікувану human-date.
  • SLA / cron-arithmetic. «Що таке 72 години від тепер у Tokyo-часі?» — відповідь у два кліки.
  • Token-expiry. JWT-claim exp — це epoch — вставте сюди для human-readable відповіді.

Про 2038-проблему

32-bit signed Unix timestamps переповнюються о 03:14:07 UTC 19 січня 2038 («Y2038»-баг). Фікс — використовувати 64-bit timestamps, що більшість сучасних мов і БД default-ить сьогодні. Наш калькулятор internally використовує 64-bit — значення після 2038, і навіть далеко після року 100 000, рахуються правильно. Legacy-системи на embedded-hardware — залишкова exposure-surface.

Часті запитання

Чому мій «timestamp» 13 цифр?

Він у мілісекундах, не секундах. JavaScript, Java і багато новіших API за замовчуванням мають millisecond-resolution; класичний Unix — секунди. 10 цифр = секунди (поточна ера до 2286), 13 цифр = мілісекунди, 16 цифр = мікросекунди, 19 цифр = наносекунди. Наш парсер детектить precision за кількістю цифр і конвертує відповідно.

Чи обробляє інструмент time zones правильно?

Так — кожна конверсія показує UTC поряд з обраною time zone (default — local zone вашого браузера). DST-переходи поважаються для IANA-zones (наприклад, «Europe/Berlin» обробляє CET/CEST-зміни автоматично). Будьте обережні з fixed-offset рядками («+02:00») — у звичайний день виглядають так само, але ігнорують DST.

Чому моя year-arithmetic-відповідь відрізняється від простого ділення?

Бо календарні одиниці нерівні. «Рік» в середньому 365.2425 днів; деякі 365, деякі 366. Віднімання двох дат у «роках і місяцях» вимагає реального календарного walking, не просто ділення секунд. Наш інструмент робить walk; просте наближення seconds / (365 * 86400) дрейфить на ~6 годин за рік.

Що таке Y2038-проблема?

32-bit signed integer Unix-timestamp переповнюється о 03:14:07 UTC 19 січня 2038. Системи, що досі використовують 32-bit time, rollover-нуть на негативне значення (інтерпретоване як 13 грудня 1901). Сучасні Linux, Windows і macOS усі використовують 64-bit timestamps, що вистачить до року 292 277 026 596. Legacy embedded-системи — залишковий ризик.