Unix Timestamp: co to jest, konwersja i przechowywanie w rozwoju mobilnym

Co to jest Unix Timestamp?

Unix Timestamp (znany również jako POSIX time, Epoch time lub Unix time) — to system pomiaru czasu, który określa liczbę sekund, jakie upłynęły od 1 stycznia 1970 roku 00:00:00 UTC (epoka Uniksa). Ta data została wybrana jako początek odliczania dla systemu operacyjnego Unix, a następnie format stał się standardem de facto dla reprezentacji czasu w systemach komputerowych. Timestamp nie uwzględnia sekund przestępnych — każda minuta jest liczona jako 60 sekund, chociaż Międzynarodowa Służba Rotacji Ziemi czasami dodaje dodatkową sekundę do korekcji czasu atomowego.

Epoka Uniksa: dlaczego rok 1970?

Wybór 1 stycznia 1970 roku wiąże się z historią rozwoju systemu operacyjnego Unix. Twórcy Ken Thompson i Dennis Ritchie wybrali tę datę jako prostą, okrągłą wartość początkową — była wystarczająco wczesna, aby pomieścić wszystkie możliwe daty, a jednocześnie wystarczająco późna, aby czas można było przechowywać w 32-bitowej liczbie całkowitej ze znakiem. Początkowo czas był mierzony w sześćdziesiętnych częściach sekundy, następnie w tikach (1/60 sekundy) i dopiero w siódmym wydaniu Uniksa (V7, 1979) format ustabilizował się jako całkowita liczba sekund. Według The Open Group Base Specifications (Issue 8, 2024), systemy zgodne z POSIX muszą obsługiwać ten format.

Jak działa Unix Timestamp

Zasada działania Unix Timestamp opiera się na prostym liczniku: każdy kolejny dzień dodaje 86 400 sekund do wartości. Na przykład timestamp 1 720 000 000 odpowiada dacie w połowie 2024 roku — dokładne przeliczenie można wykonać, dzieląc przez liczbę sekund w dobie, godzinie i minucie. Takie podejście czyni timestamp idealnym do przechowywania maszynowego: jest to liczba całkowita zajmująca 4 bajty (32-bitowy int) lub 8 bajtów (64-bitowy long) i obsługująca bezpośrednie porównanie — większy timestamp = późniejsza data.

Matematyka konwersji

Jeden dzień = 86 400 sekund (24 x 60 x 60). Jedna godzina = 3600 sekund. Aby przekonwertować timestamp na datę, należy kolejno obliczyć liczbę dni, godzin, minut i sekund od początku epoki. Odwrotna konwersja — przeliczyć datę na dni od 1970-01-01, następnie pomnożyć przez 86 400 i dodać przesunięcie względem UTC. W Javie i Kotlinie te obliczenia są już zaimplementowane w standardowych klasach java.time.Instant i java.util.Date, co zwalnia programistę z ręcznych obliczeń.

        // Pobierz Unix Timestamp w sekundach
val seconds = System.currentTimeMillis() / 1000

// Konwertuj timestamp na datę przez java.time
val instant = Instant.ofEpochSecond(seconds)
val localDate = instant.atZone(ZoneId.of("Europe/Moscow")).toLocalDate()

// Odwrotność: data na timestamp
val date = LocalDate.of(2026, 7, 21)
val ts = date.atStartOfDay(ZoneOffset.UTC).toEpochSecond()

Konwersja Unix Timestamp na datę i odwrotnie

Konwersja Unix Timestamp na datę czytelną dla człowieka to jedna z najczęstszych operacji w rozwoju aplikacji mobilnych. Na Androidzie dostępnych jest kilka sposobów konwersji w zależności od minimalnej wersji API: dla API 26+ zaleca się java.time.Instant, dla starszych wersji używa się java.util.Date i java.text.SimpleDateFormat. Ważne jest, aby pamiętać, że Android i JVM domyślnie używają milisekund, a nie sekund — jeśli timestamp został odebrany z serwera w sekundach, należy go pomnożyć przez 1000 przed przekazaniem do standardowych konstruktorów.

Konwersja z uwzględnieniem strefy czasowej

Jedną z głównych zalet Unix Timestamp jest niezależność od lokalizacji. Serwer zawsze zwraca timestamp w UTC, a konwersję na lokalną datę i czas wykonuje się po stronie klienta. W Kotlinie służy do tego ZonedDateTime z odpowiednim ZoneId — systemowym lub wybranym przez użytkownika. Jeśli aplikacja wyświetla czas w różnych strefach (na przykład dla podróżników), timestamp eliminuje konieczność przesyłania strefy czasowej z serwera — wystarczy jeden uniwersalny znacznik czasu.

// Konwersja z uwzględnieniem strefy czasowej użytkownika
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))
}

// Przykład: timestamp = 1720000000, strefa = Europe/Moscow
val result = formatTimestamp(1720000000, ZoneId.of("Europe/Moscow"))

Problem roku 2038

Problem roku 2038 (Year 2038 Problem, Y2K38) — fundamentalne ograniczenie 32-bitowej liczby całkowitej ze znakiem do przechowywania Unix Timestamp. Maksymalna wartość 32-bitowego signed int wynosi 2 147 483 647, co odpowiada 19 stycznia 2038 roku 03:14:07 UTC. Po tej dacie wartość się przepełnia i zamienia się w liczbę ujemną, co powoduje awarie w systemach używających 32-bitowego time_t. Problem jest analogiczny do znanego Y2K, ale dotyczy przede wszystkim systemów wbudowanych, starszych wersji Android i urządzeń IoT z architekturą 32-bitową.

Skala problemu

Według Linux Foundation (2025), około 15% urządzeń z systemem Linux w segmencie przemysłowym i IoT wciąż używa kompilacji 32-bitowych. W przypadku urządzeń Android ryzyko jest niższe — większość nowoczesnych smartfonów działa na procesorach 64-bitowych (ARM64), jednak starsze modele z Android 4.x i niżej mogą używać 32-bitowego time_t. Rozwiązaniem problemu jest migracja na 64-bitowy time_t, który jest bezpieczny przez 292 miliardy lat. Od Android 5.0 (API 21) wszystkie urządzenia używają czasu 64-bitowego na poziomie jądra. Programistom aplikacji mobilnych wystarczy przechowywać timestamp w typie Long (64-bitowy), aby uniknąć problemu na poziomie aplikacji.

Praca z Unix Timestamp w Android

W rozwoju aplikacji na Androida poprawna praca z Unix Timestamp jest kluczowa do synchronizacji danych, wyświetlania czasu otrzymania wiadomości, obliczania limitów czasowych i planowania powiadomień. Wywołanie systemowe System.currentTimeMillis() zwraca bieżący czas w milisekundach od epoki Uniksa — jest to najdokładniejsze źródło czasu dostępne na urządzeniu. W przypadku żądań sieciowych zwykle używa się Unix Timestamp w sekundach, ponieważ większość REST API i baz danych operuje właśnie na sekundach.

Zalecane praktyki

Nigdy nie używaj System.currentTimeMillis() do pomiaru interwałów — do tego służy System.nanoTime(), który jest monotoniczny i nie zależy od zmian czasu dokonywanych przez użytkownika. Do wyświetlania czasu zawsze przechowuj timestamp w UTC i konwertuj na lokalną strefę czasową po stronie interfejsu. Podczas pracy z bazami danych (SQLite, Room) używaj typu INTEGER i przechowuj timestamp w sekundach — zajmuje to 8 bajtów (Long) i obsługuje natywne sortowanie SQL. Do serializacji w JSON zaleca się przesyłanie timestamp jako liczby (Long), a nie ciągu znaków — jest to bardziej zwięzłe i szybciej się parsuje.

// Prawidłowy pomiar czasu wykonania
val start = System.nanoTime()
// ... operacja ...
val elapsed = System.nanoTime() - start
val seconds = elapsed / 1_000_000_000.0

// Przechowuj w Room (Entity)
@Entity
data class Message(
    @PrimaryKey val id: Long,
    val text: String,
    val createdAt: Long // Unix Timestamp w sekundach
)

Obsługa czasu z serwera

Przy odbieraniu Unix Timestamp z serwera zawsze sprawdzaj jednostkę miary: niektóre API zwracają milisekundy (zgodne z JavaScript), inne — sekundy (standard POSIX). Uzgodnienie jednostek powinno być zapisane w dokumentacji API. W odpowiedzi serwera timestamp może być przesłany jako Long (liczba JSON) lub String (ISO 8601). Do debugowania dodaj funkcję pomocniczą, która wyświetla timestamp w formacie czytelnym dla człowieka — upraszcza to weryfikację poprawności znaczników czasu podczas rozwoju.

Przechowywanie znaczników czasu w bazach danych

Wybór formatu przechowywania czasu w bazie danych bezpośrednio wpływa na wydajność zapytań, złożoność kodu i poprawność pracy ze strefami czasowymi. Unix Timestamp to najbardziej wydajny format dla relacyjnych baz danych: jest przechowywany jako liczba całkowita (4 lub 8 bajtów), obsługuje indeksowanie i szybkie sortowanie. W przeciwieństwie do ciągów ISO 8601, timestamp nie wymaga parsowania przy sortowaniu i zajmuje mniej miejsca w indeksie. W przypadku Room i SQLite zaleca się przechowywanie timestamp w typie INTEGER i używanie indeksu na kolumnie czasu.

Zalecenia dla projektów mobilnych

W przypadku aplikacji Android z biblioteką Room zaleca się przechowywanie timestamp jako Long (64-bitowy) i używanie TypeConverter do automatycznej konwersji między Long a Date lub Instant. Przy zapytaniach do bazy używaj operatorów porównania (>, <, BETWEEN) — działają one natywnie z typami całkowitymi. Do buforowania danych wymagających sortowania według czasu (na przykład lista wiadomości) koniecznie utwórz indeks na kolumnie timestamp — przyspieszy to zapytania z ORDER BY o kilka rzędów wielkości przy dużej objętości danych.