Unix Timestamp: ce este, conversia și stocarea în dezvoltarea mobilă

Ce este Unix Timestamp?

Unix Timestamp (cunoscut și ca POSIX time, Epoch time sau Unix time) — este un sistem de măsurare a timpului care determină numărul de secunde scurse de la 1 ianuarie 1970 00:00:00 UTC (epoca Unix). Această dată a fost aleasă ca început de numărătoare pentru sistemul de operare Unix, iar ulterior formatul a devenit standardul de facto pentru reprezentarea timpului în sistemele informatice. Timestamp nu ia în considerare secundele bisecte — fiecare minut este considerat 60 de secunde, deși Serviciul Internațional de Rotație a Pământului adaugă uneori o secundă suplimentară pentru corectarea timpului atomic.

Epoca Unix: de ce 1970?

Alegerea datei de 1 ianuarie 1970 este legată de istoria dezvoltării sistemului de operare Unix. Dezvoltatorii Ken Thompson și Dennis Ritchie au ales această dată ca un punct de plecare simplu și rotund — era suficient de devreme pentru a cuprinde toate datele posibile și, în același timp, suficient de târziu pentru ca timpul să poată fi stocat într-un număr întreg cu semn pe 32 de biți. Inițial timpul era măsurat în zecimi de secundă, apoi în tick-uri (1/60 de secundă), iar abia în cea de-a șaptea ediție a Unix (V7, 1979) formatul s-a stabilizat ca număr întreg de secunde. Conform The Open Group Base Specifications (Issue 8, 2024), sistemele compatibile POSIX sunt obligate să suporte acest format.

Cum funcționează Unix Timestamp

Principiul de funcționare al Unix Timestamp se bazează pe un simplu contor: fiecare zi scursă adaugă 86 400 de secunde la valoare. De exemplu, timestamp 1 720 000 000 corespunde unei date la mijlocul anului 2024 — conversia exactă se poate face prin împărțirea la numărul de secunde dintr-o zi, oră și minut. O astfel de abordare face timestamp-ul ideal pentru stocarea mașină: este un număr întreg care ocupă 4 octeți (int pe 32 de biți) sau 8 octeți (long pe 64 de biți) și suportă compararea directă — timestamp mai mare = dată mai târzie.

Matematica conversiei

O zi = 86 400 de secunde (24 x 60 x 60). O oră = 3600 de secunde. Pentru a converti timestamp-ul în dată, trebuie să calculați succesiv numărul de zile, ore, minute și secunde de la începutul epocii. Conversia inversă — transformați data în zile de la 1970-01-01, apoi înmulțiți cu 86 400 și adăugați deplasarea față de UTC. În Java și Kotlin, aceste calcule sunt deja implementate în clasele standard java.time.Instant și java.util.Date, ceea ce scutește dezvoltatorul de calcule manuale.

        // Obțineți Unix Timestamp în secunde
val seconds = System.currentTimeMillis() / 1000

// Convertiți timestamp-ul în dată prin java.time
val instant = Instant.ofEpochSecond(seconds)
val localDate = instant.atZone(ZoneId.of("Europe/Moscow")).toLocalDate()

// Invers: data în timestamp
val date = LocalDate.of(2026, 7, 21)
val ts = date.atStartOfDay(ZoneOffset.UTC).toEpochSecond()

Conversia Unix Timestamp în dată și invers

Conversia Unix Timestamp într-o dată lizibilă pentru om este una dintre cele mai frecvente operații în dezvoltarea mobilă. Pe Android sunt disponibile mai multe metode de conversie în funcție de versiunea minimă API: pentru API 26+ se recomandă java.time.Instant, pentru versiunile mai vechi se folosește java.util.Date și java.text.SimpleDateFormat. Este important să rețineți că Android și JVM folosesc implicit milisecunde, nu secunde — dacă timestamp-ul a fost primit de la server în secunde, trebuie înmulțit cu 1000 înainte de a fi transmis constructorilor standard.

Conversia cu fusul orar al utilizatorului

Unul dintre principalele avantaje ale Unix Timestamp este independența de locație. Serverul returnează întotdeauna timestamp-ul în UTC, iar conversia în data și ora locală se face pe partea clientului. În Kotlin, pentru aceasta se folosește ZonedDateTime cu un ZoneId corespunzător — sistemic sau ales de utilizator. Dacă aplicația afișează timpul în diferite fusuri orare (de exemplu, pentru călători), timestamp elimină necesitatea de a transmite fusul orar de la server — un singur marcaj de timp este suficient.

// Conversia cu fusul orar al utilizatorului
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))
}

// Exemplu: timestamp = 1720000000, fus = Europe/Moscow
val result = formatTimestamp(1720000000, ZoneId.of("Europe/Moscow"))

Problema anului 2038

Problema anului 2038 (Year 2038 Problem, Y2K38) — este o limitare fundamentală a numărului întreg cu semn pe 32 de biți pentru stocarea Unix Timestamp. Valoarea maximă a unui signed int pe 32 de biți este 2 147 483 647, ceea ce corespunde datei de 19 ianuarie 2038, ora 03:14:07 UTC. După această dată, valoarea se depășește și se transformă într-un număr negativ, ceea ce cauzează defecțiuni în sistemele care folosesc time_t pe 32 de biți. Problema este similară cu celebra Y2K, dar afectează în primul rând sistemele încorporate, versiunile vechi de Android și dispozitivele IoT cu arhitectură pe 32 de biți.

Amploarea problemei

Conform Linux Foundation (2025), aproximativ 15% dintre dispozitivele Linux din segmentul industrial și IoT folosesc încă compilări pe 32 de biți. Pentru dispozitivele Android, riscul este mai scăzut — majoritatea smartphone-urilor moderne funcționează pe procesoare pe 64 de biți (ARM64), dar modelele mai vechi cu Android 4.x și inferioară pot folosi time_t pe 32 de biți. Soluția problemei — migrarea la time_t pe 64 de biți, care este sigur timp de 292 de miliarde de ani. începând cu Android 5.0 (API 21), toate dispozitivele folosesc timp pe 64 de biți la nivel de kernel. Dezvoltatorilor de aplicații mobile le este suficient să stocheze timestamp-ul în tipul Long (64 de biți) pentru a evita problema la nivel de aplicație.

Lucrul cu Unix Timestamp în Android

În dezvoltarea Android, lucrul corect cu Unix Timestamp este critic pentru sincronizarea datelor, afișarea timpului de primire a mesajelor, calcularea timeout-urilor și programarea notificărilor. Apelul de sistem System.currentTimeMillis() returnează timpul curent în milisecunde de la epoca Unix — aceasta este cea mai precisă sursă de timp disponibilă pe dispozitiv. Pentru solicitările de rețEA, se folosește de obicei Unix Timestamp în secunde, deoarece majoritatea REST API-urilor și bazelor de date operează exact cu secunde.

Practici recomandate

Nu folosiți niciodată System.currentTimeMillis() pentru măsurarea intervalelor — pentru aceasta există System.nanoTime(), care este monotonă și nu depinde de modificările de ceas ale utilizatorului. Pentru afișarea timpului, stocați întotdeauna timestamp-ul în UTC și convertiți-l în fusul orar local pe partea de interfață. La lucrul cu baze de date (SQLite, Room), folosiți tipul INTEGER și stocați timestamp-ul în secunde — aceasta ocupă 8 octeți (Long) și suportă sortarea nativă SQL. Pentru serializarea în JSON, se recomandă trimiterea timestamp-ului ca număr (Long), nu ca șir de caractere — este mai compact și se parsează mai repede.

// Măsurarea corectă a timpului de execuție
val start = System.nanoTime()
// ... operațiunea ...
val elapsed = System.nanoTime() - start
val seconds = elapsed / 1_000_000_000.0

// Stocați în Room (Entity)
@Entity
data class Message(
    @PrimaryKey val id: Long,
    val text: String,
    val createdAt: Long // Unix Timestamp în secunde
)

Gestionarea timpului de la server

La primirea Unix Timestamp de la server, verificați întotdeauna unitatea de măsură: unele API-uri returnează milisecunde (compatibile cu JavaScript), altele — secunde (standardul POSIX). Înțelegerea asupra unităților trebuie să fie documentată în specificațiile API. în răspunsul serverului, timestamp poate fi transmis ca Long (număr JSON) sau String (ISO 8601). Pentru depanare, adăugați o funcție utilitară care afișează timestamp-ul în format lizibil pentru om — aceasta simplifică verificarea corectitudinii marcajelor de timp în timpul dezvoltării.

Stocarea marcajelor de timp în bazele de date

Alegerea formatului de stocare a timpului în baza de date influențează direct performanța interogărilor, complexitatea codului și corectitudinea lucrului cu fusurile orare. Unix Timestamp — cel mai eficient format pentru bazele de date relaționale: este stocat ca număr întreg (4 sau 8 octeți), suportă indexare și sortare rapidă. Spre deosebire de șirurile ISO 8601, timestamp nu necesită parsare la sortare și ocupă mai puțin spațiu în index. Pentru Room și SQLite, se recomandă stocarea timestamp-ului în tipul INTEGER și utilizarea unui index pe coloana de timp.

Recomandări pentru proiecte mobile

Pentru aplicațiile Android cu biblioteca Room, se recomandă stocarea timestamp-ului ca Long (64 de biți) și utilizarea TypeConverter pentru conversia automată între Long și Date sau Instant. La interogările bazei de date, folosiți operatorii de comparare (>, <, BETWEEN) — aceștia funcționează nativ cu tipurile numerice. Pentru cache-ul datelor care necesită sortare după timp (de exemplu, lista de mesaje), creați obligatoriu un index pe coloana timestamp — aceasta va accelera interogările cu ORDER BY de câteva ordine de mărime la volume mari de date.