Unix Timestamp: що це, конвертація та зберігання в мобільній розробці

Що таке Unix Timestamp?

Unix Timestamp (також відомий як POSIX time, Epoch time або Unix time) — це система вимірювання часу, яка визначає кількість секунд, що минули з 1 січня 1970 року 00:00:00 UTC (епоха Unix). Ця дата була обрана як точка відліку для операційної системи Unix, і згодом формат став стандартом де-факто для представлення часу в обчислювальних системах. Timestamp не враховує високосні секунди — кожна хвилина вважається за 60 секунд, хоча Міжнародна служба обертання Землі іноді додає додаткову секунду для корекції атомного часу.

Епоха Unix: чому 1970 рік?

Вибір 1 січня 1970 року пов'язаний з історією розвитку операційної системи Unix. Розробники Ken Thompson та Dennis Ritchie обрали цю дату як простий круглий відлік — вона була достатньо ранньою, щоб вмістити всі можливі дати, і при цьому достатньо пізньою, щоб час можна було зберігати в 32-бітному знаковому цілому числі. Спочатку час вимірювався в шістдесятих частках секунди, потім у тіках (1/60 секунди), і лише до сьомого видання Unix (V7, 1979 рік) формат стабілізувався як ціла кількість секунд. За даними The Open Group Base Specifications (Issue 8, 2024), POSIX-сумісні системи зобов'язані підтримувати цей формат.

Як влаштований Unix Timestamp

Принцип роботи Unix Timestamp заснований на простому лічильнику: кожен минулий день додає 86 400 секунд до значення. Наприклад, timestamp 1 720 000 000 відповідає даті в середині 2024 року — точне перетворення можна виконати діленням на кількість секунд у добі, годині та хвилині. Такий підхід робить timestamp ідеальним для машинного зберігання: це ціле число, яке займає 4 байти (32-бітний int) або 8 байтів (64-бітний long) та підтримує пряме порівняння — більший timestamp = пізніша дата.

Математика перетворення

Один день = 86 400 секунд (24 x 60 x 60). Одна година = 3600 секунд. Щоб перетворити timestamp на дату, потрібно послідовно обчислити кількість днів, годин, хвилин і секунд від початку епохи. Зворотне перетворення — перевести дату в дні від 1970-01-01, потім помножити на 86 400 та додати зміщення від UTC. У Java та Kotlin ці обчислення вже реалізовані в стандартних класах java.time.Instant та java.util.Date, що позбавляє розробника від ручних розрахунків.

        // Отримати Unix Timestamp у секундах
val seconds = System.currentTimeMillis() / 1000

// Конвертувати timestamp у дату через java.time
val instant = Instant.ofEpochSecond(seconds)
val localDate = instant.atZone(ZoneId.of("Europe/Moscow")).toLocalDate()

// Зворотньо: дата в timestamp
val date = LocalDate.of(2026, 7, 21)
val ts = date.atStartOfDay(ZoneOffset.UTC).toEpochSecond()

Конвертація Unix Timestamp у дату та назад

Конвертація Unix Timestamp у зрозумілу для людини дату — одна з найчастіших операцій у мобільній розробці. На Android доступно кілька способів перетворення залежно від мінімальної версії API: для API 26+ рекомендується java.time.Instant, для старіших версій використовується java.util.Date та java.text.SimpleDateFormat. Важливо пам'ятати, що Android та JVM за замовчуванням використовують мілісекунди, а не секунди — якщо timestamp отримано з сервера в секундах, його потрібно помножити на 1000 перед передачею в стандартні конструктори.

Перетворення з урахуванням часового поясу

Одна з головних переваг Unix Timestamp — незалежність від локації. Сервер завжди повертає timestamp в UTC, а перетворення в локальну дату та час виконується на стороні клієнта. У Kotlin для цього використовується ZonedDateTime з потрібним ZoneId — системним або вибраним користувачем. Якщо застосунок показує час у різних поясах (наприклад, для мандрівників), timestamp позбавляє необхідності передавати часовий пояс із сервера — достатньо єдиної часової мітки.

// Конвертувати з часовим поясом користувача
fun formatTimestamp(seconds: Long, zoneId: ZoneId): String {
    val instant = Instant.ofEpochSecond(seconds)
    val formatter = DateTimeFormatter
        .ofPattern("dd.MM.yyyy HH:mm:ss")
    return formatter.format(instant.atZone(zoneId))
}

// Приклад: timestamp = 1720000000, zone = Europe/Moscow
val result = formatTimestamp(1720000000, ZoneId.of("Europe/Moscow"))

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

Проблема 2038 року (Year 2038 Problem, Y2K38) — фундаментальне обмеження 32-бітного знакового цілого числа для зберігання Unix Timestamp. Максимальне значення 32-бітного signed int — 2 147 483 647, що відповідає 19 січня 2038 року 03:14:07 UTC. Після цієї дати значення переповнюється і перетворюється на від'ємне число, що викликає збої в системах, які використовують 32-бітний time_t. Проблема аналогічна відомій Y2K, але зачіпає в першу чергу вбудовані системи, старі версії Android та IoT-пристрої з 32-бітною архітектурою.

Масштаб проблеми

За даними Linux Foundation (2025), близько 15% пристроїв на Linux у промисловому та IoT-сегменті все ще використовують 32-бітні збірки. Для Android-пристроїв ризик нижчий — більшість сучасних смартфонів працюють на 64-бітних процесорах (ARM64), однак старі моделі з Android 4.x і нижче можуть використовувати 32-бітний time_t. Рішення проблеми — міграція на 64-бітний time_t, який безпечний до 292 мільярдів років. Починаючи з Android 5.0 (API 21), усі пристрої використовують 64-бітний час на рівні ядра. Розробникам мобільних застосунків достатньо зберігати timestamp у типі Long (64-бітний), щоб уникнути проблеми на рівні застосунку.

Робота з Unix Timestamp в Android

У Android-розробці правильна робота з Unix Timestamp критична для синхронізації даних, відображення часу отримання повідомлень, розрахунку таймаутів та планування сповіщень. Системний виклик System.currentTimeMillis() повертає поточний час у мілісекундах з епохи Unix — це найточніше джерело часу, доступне на пристрої. Для мережевих запитів зазвичай використовується Unix Timestamp у секундах, оскільки більшість REST API та баз даних оперують саме секундами.

Рекомендовані практики

Ніколи не використовуйте System.currentTimeMillis() для вимірювання інтервалів — для цього існує System.nanoTime(), яка монотонна і не залежить від переведень годинника користувачем. Для відображення часу завжди зберігайте timestamp в UTC і конвертуйте в локальний часовий пояс на стороні UI. При роботі з базами даних (SQLite, Room) використовуйте тип INTEGER і зберігайте timestamp у секундах — це займає 8 байтів (Long) і підтримує нативне сортування SQL. Для серіалізації в JSON рекомендується надсилати timestamp як число (Long), а не рядок — це компактніше і швидше парситься.

// Правильне вимірювання часу виконання
val start = System.nanoTime()
// ... операція ...
val elapsed = System.nanoTime() - start
val seconds = elapsed / 1_000_000_000.0

// Зберігати в Room (Entity)
@Entity
data class Message(
    @PrimaryKey val id: Long,
    val text: String,
    val createdAt: Long // Unix Timestamp у секундах
)

Обробка часу з сервера

При отриманні Unix Timestamp з сервера завжди перевіряйте одиницю вимірювання: деякі API повертають мілісекунди (JavaScript-сумісні), інші — секунди (стандарт POSIX). Домовленість про одиниці має бути зафіксована в документації API. У відповіді сервера timestamp може бути переданий як Long (JSON-число) або String (ISO 8601). Для налагодження додайте утилітарну функцію, яка виводить timestamp у зрозумілому для людини форматі — це спрощує перевірку коректності часових міток під час розробки.

Зберігання часових міток у базах даних

Вибір формату зберігання часу в базі даних безпосередньо впливає на продуктивність запитів, складність коду та коректність роботи з часовими поясами. Unix Timestamp — найбільш ефективний формат для реляційних БД: він зберігається як ціле число (4 або 8 байтів), підтримує індексацію та швидке сортування. На відміну від рядків ISO 8601, timestamp не потребує парсингу при сортуванні та займає менше місця в індексі. Для Room та SQLite рекомендується зберігати timestamp у типі INTEGER та використовувати індекс на колонці часу.

Рекомендації для мобільних проєктів

Для Android-застосунків з Room бібліотекою рекомендується зберігати timestamp як Long (64-бітний) і використовувати TypeConverter для автоматичної конвертації між Long та Date або Instant. При запитах до бази використовуйте оператори порівняння (>, <, BETWEEN) — вони працюють нативно з цілочисельними типами. Для кешування даних, що потребують сортування за часом (наприклад, список повідомлень), обов'язково створіть індекс на колонці timestamp — це прискорить запити з ORDER BY на кілька порядків при великому обсязі даних.