Unix time представляє момент як кількість одиниць від спільної точки відліку — початку 1970 року в UTC. Ця проста ідея дозволяє різним системам порівнювати, зберігати й передавати час без назв місяців, локального формату та timezone в кожному значенні. Timestamp сортує події, завершує строк token, запускає job і вимірює історію. Проте за простим числом ховаються питання про секунди й мілісекунди, якість системного годинника, leap seconds, діапазон і різницю між глобальним моментом та людським календарем.

Момент не є відформатованою датою

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

Це розділення корисне: система зберігає один недвозначний момент, а інтерфейс показує його відповідно до locale. Проблеми починаються, коли локальний wall-clock час помилково сприймають як уже визначений глобальний instant.

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

Класичний Unix timestamp рахує секунди, а JavaScript та багато API використовують мілісекунди. Значення відрізняються у тисячу разів. Мілісекунди, прочитані як секунди, дають дату в далекому майбутньому; секунди, прочитані як мілісекунди, переносять подію близько до 1970 року.

Назва поля та схема повинні явно показувати одиницю: created_at_ms або ISO 8601-рядок зрозуміліші за невідоме integer. Визначення одиниці за кількістю цифр допомагає під час діагностики, але не повинно бути production-контрактом.

Системний годинник є вимірюванням

Timestamp зазвичай походить із machine clock, а годинники можуть помилятися. Вони drift-ять, синхронізуються через мережу, стрибають після correction і відрізняються між серверами. Wall clock підходить для запису приблизного реального моменту, але небезпечний для вимірювання duration, бо після correction час може піти назад або різко вперед.

Для timeout, retry та elapsed duration потрібно використовувати monotonic clock. Він рухається послідовно, але не має календарного значення поза процесом. Wall time та elapsed time відповідають на різні питання й потребують різних API.

Leap seconds ускладнюють ідеальну шкалу

Обертання Землі не є абсолютно рівномірним, тому цивільний час іноді отримував leap second. Реалізації Unix time зазвичай не представляють таку секунду як окремий універсальний timestamp. Система може повторити секунду, розтягнути correction або діяти за platform-specific правилом.

Більшість бізнес-застосунків може покладатися на стандартну поведінку платформи. Наукові, фінансові та distributed systems із жорсткими вимогами повинні розуміти джерело часу й synchronization policy. Позначка UTC не усуває всіх implementation details.

Діапазон і точність мають межі

Старі системи з signed 32-bit seconds стикаються з проблемою 2038 року. Сучасні 64-bit representations мають великий запас, але database type, file format або зовнішній API можуть підтримувати менший діапазон. Floating-point timestamp також втрачає sub-second precision для великих значень.

Представлення потрібно вибирати за реальною точністю й діапазоном. Nanoseconds корисні для tracing, але вводять в оману, якщо clock не вимірює їх надійно. Більше цифр не означає точнішу правду.

Зберігайте instant лише для подій, що справді відбуваються

Creation time, log entry, transaction та token expiration є моментами й добре зберігаються в UTC. Повторювана людська подія — інша модель. «Щодня о 9:00 у Києві» є правилом, пов’язаним із timezone та daylight saving, а не одним постійним offset або timestamp.

Для одноразової зустрічі локальну дату й timezone перетворюють на instant. Для recurring event зберігають local time, recurrence rule та IANA timezone, щоб майбутні occurrence слідували локальному календарю.

Database type кодує припущення

Бази даних мають кілька типів date і timestamp з різною поведінкою щодо timezone та діапазону. Один нормалізує значення до UTC, інший зберігає wall-clock text без zone context. Неправильний вибір може непомітно переінтерпретувати дані під час читання або міграції сервера.

Документуйте, чи колонка містить instant, local date або local date-time. Application і database session timezone повинні бути налаштовані свідомо, а не успадковані від випадкової машини.

Конвертація повинна зберігати сенс

Перед конвертацією визначте одиницю та тип значення. Для технічного обміну показуйте explicit timezone і недвозначний формат на кшталт ISO 8601. Людський інтерфейс може додати локалізовану форму, але logs та API не повинні використовувати неоднозначні числові дати.

Документація має містити реальні приклади з offset і sub-second precision. Один точний приклад часто виявляє приховане припущення швидше за загальну фразу «поле містить timestamp».

Unix time є спільним знаменником, а не повною моделлю

API має називати точність і правила округлення

Якщо producer записує мікросекунди, а consumer зберігає лише секунди, порядок близьких подій може змінитися. Відсікання та округлення також дають різні результати на межі. Контракт повинен визначати precision і те, чи зайві цифри відхиляються або втрачаються.

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

Timestamp у логах має бути послідовним

Distributed logs корисні лише тоді, коли всі сервіси записують UTC, достатню точність і зрозумілий формат. Локальний час без offset ускладнює incident investigation та порівняння подій між регіонами.

Разом із timestamp варто зберігати request або trace identifier. Час допомагає звузити пошук, але causal relationship краще показує зв’язок подій.

Unix time є спільним знаменником, а не повною моделлю

Timestamp чудово працює для справжніх instant з явною одиницею та зрозумілим джерелом годинника. Він не замінює local date, recurring schedule, timezone або duration.

Надійна система спочатку визначає сенс часу, а потім вибирає представлення. Це просте правило запобігає помилкам, які проявляються лише після зміни timezone, clock correction або інтеграції з іншою платформою.