Конвертер Unix timestamp у дату

Що таке Unix timestamp?

Unix timestamp, також звана Unix time або POSIX time, — це кількість секунд, які минули з 1970-01-01 00:00:00 UTC, момент, відомий як Unix epoch. Це широко використовуваний стандарт у комп'ютерах, оскільки він представляє момент часу як одне число, що спрощує зберігання, порівняння та математичні операції.

JavaScript працює внутрішньо в мілісекундах, тому Date.now() повертає Unix timestamp, помножений на 1000. Багато API, баз даних і бекенд-систем використовують замість цього секунди. Цей інструмент приймає обидва формати й автоматично визначає, чи ви ввели секунди чи мілісекунди, на основі величини числа.

Значущі Unix timestamps

Чому 1970?

Epoch Unix від 1 січня 1970 року була обрана частково за традицією, частково через практичні обмеження. Unix розроблялась у кінці 1960-х і на початку 1970-х років у Bell Labs. Розробникам потрібна була свіжа, кругла дата для початку їх системи часу. 1 січня 1970 року була досить свіжою для практичного використання й не мала особливого технічного значення — це була просто зручна точка відліку.

Інші системи використовують інші дати epoch: Windows FILETIME починається з 1 січня 1601; GPS time почалась 6 січня 1980; NTP epoch — 1 січня 1900. При конвертації між системами важливо знати epoch кожної з них.

Секунди проти мілісекунд

Оригінальний Unix timestamp вимірюється в секундах. Більшість мов серверної сторони й систем (Unix shell, Python time.time(), PHP time(), більшість баз даних) використовують секунди. JavaScript Date.now() та new Date().getTime() повертають мілісекунди. Ця невідповідність часто становить джерело помилок, коли JavaScript фронтенд спілкується з бекенд-API.

Unix timestamp у секундах на даний момент — це 10-значне число (біля 1,700,000,000 станом на 2023). Timestamp у мілісекундах — це 13-значне число. Калькулятор визначає, який формат ви ввели, на основі кількості цифр і конвертує його відповідно.

Проблема 2038 року

Системи, які зберігають Unix timestamps як знаковане 32-бітне число, можуть представляти дати тільки до 2,147,483,647 секунд після epoch — це 03:14:07 UTC 19 січня 2038 року. Після цього моменту 32-бітне знакове число переповнюється в велике від'ємне число, що представляє дату в 1901 році.

Це іноді називають проблемою "Y2K38" або Unix Millennium Bug. Сучасні 64-бітні системи не постраждають, оскільки 64-бітне знакове число може представляти timestamps приблизно на 292 мільярди років. Однак вбудовані системи, застарілі бази даних і старіше 32-бітне ПО можуть залишатись уразливими. Багато галузей — включно з телекомунікаціями, банківством та системами промислової автоматики — проводять постійну міграцію для вирішення цієї проблеми.

Як отримати поточний Unix timestamp

Практичне застосування

Розробка API: REST API зазвичай використовують Unix timestamps для полів created_at, updated_at та терміну дії токена. Timestamp не залежить від часового поясу й однозначний — на відміну від форматованих рядків дати, які залежать від локалі й правил форматування.

Термін дії токена: JWT (JSON Web Tokens) використовують Unix timestamps для claims exp (термін дії) та iat (дата видачі). Токен закінчується, коли поточний timestamp перевищує значення exp. Розрахунок терміну дії — "цей токен повинен закінчитися за 24 години" — потребує додавання 86,400 секунд до поточного timestamp.

Cache TTL: Закінчення терміну дії кешу часто встановлюється як Unix timestamp або як кількість секунд від тепер. Відладка проблем кешу часто потребує конвертування збереженого timestamp закінчення в читабельний формат дати.

Аналіз логів: Логи серверів часто містять Unix timestamps. Конвертування їх у читабельні дати — перший крок при кореляції записів логу з реальними подіями.

Зберігання в базі даних: Збереження timestamps як чисел замість форматованих рядків уникає помилок конвертування часових поясів і спрощує сортування, запити за діапазонами та математичні операції. Запит "всі записи за останні 7 днів" стає WHERE created_at > (NOW_UNIX - 604800).