Unix Timestamp: mi ez, konvertálás és tárolás mobil fejlesztésben

Mi az Unix Timestamp?

Unix Timestamp (más néven POSIX time, Epoch time vagy Unix time) — egy időmérő rendszer, amely meghatározza az 1970. január 1. 00:00:00 UTC (Unix korszak) óta eltelt másodpercek számát. Ezt a dátumot választották a számlálás kezdetének az Unix operációs rendszer számára, és később a formátum de facto szabvánnyá vált az idő megjelenítésére számítógépes rendszerekben. A timestamp nem veszi figyelembe a szökőmásodperceket — minden perc 60 másodpercnek számít, bár a Nemzetközi Földforgási Szolgálat néha hozzáad egy plusz másodpercet az atomidő korrekciójához.

Unix korszak: miért 1970?

Az 1970. január 1. választása az Unix operációs rendszer fejlesztésének történetéhez kapcsolódik. A fejlesztők Ken Thompson és Dennis Ritchie ezt a dátumot választották egyszerű és kerek kezdőpontként — elég korai volt ahhoz, hogy az összes lehetséges dátumot lefedje, és egyben elég késői ahhoz, hogy az idő egy 32-bites előjeles egész számban tárolható legyen. Kezdetben az időt másodperc hatvanadrészében, majd tick-ekben (1/60 másodperc) mérték, és csak az Unix hetedik kiadásában (V7, 1979) stabilizálódott a formátum egész másodpercek számaként. A The Open Group Base Specifications (Issue 8, 2024) szerint a POSIX-kompatibilis rendszerek kötelesek támogatni ezt a formátumot.

Hogyan működik az Unix Timestamp

Az Unix Timestamp működési elve egy egyszerű számlálón alapul: minden eltelt nap 86 400 másodpercet ad hozzá az értékhez. Például az 1 720 000 000 timestamp egy 2024 közepi dátumnak felel meg — a pontos átváltás elvégezhető a napi, óránkénti és percenkénti másodpercek számával való osztással. Ez a megközelítés ideálissá teszi a timestamp-et gépi tároláshoz: egy egész szám, amely 4 bájtot (32-bites int) vagy 8 bájtot (64-bites long) foglal el és támogatja a közvetlen összehasonlítást — nagyobb timestamp = későbbi dátum.

Konvertálás matematikája

Egy nap = 86 400 másodperc (24 x 60 x 60). Egy óra = 3600 másodperc. A timestamp dátummá alakításához egymás után ki kell számítani a napok, órák, percek és másodpercek számát a korszak kezdetétől. Fordított konvertálás — a dátum átalakítása napokká 1970-01-01 óta, majd szorzás 86 400-zal és az UTC-től való eltérés hozzáadása. Java-ban és Kotlin-ban ezek a számítások már implementálva vannak a java.time.Instant és java.util.Date szabvány osztályokban, ami megkíméli a fejlesztőt a kézi számításoktól.

        // Szerezze meg az Unix Timestamp-et másodpercekben
val seconds = System.currentTimeMillis() / 1000

// Konvertálja a timestamp-et dátummá java.time segítségével
val instant = Instant.ofEpochSecond(seconds)
val localDate = instant.atZone(ZoneId.of("Europe/Moscow")).toLocalDate()

// Fordítva: dátum timestamp-pé
val date = LocalDate.of(2026, 7, 21)
val ts = date.atStartOfDay(ZoneOffset.UTC).toEpochSecond()

Unix Timestamp konvertálása dátummá és vissza

Az Unix Timestamp ember által olvasható dátummá alakítása az egyik leggyakoribb művelet a mobil fejlesztésben. Androidban több konvertálási módszer érhető el a minimális API verziótól függően: API 26+ esetén a java.time.Instant ajánlott, régebbi verziók esetén a java.util.Date és java.text.SimpleDateFormat használatos. Fontos megjegyezni, hogy az Android és a JVM alapértelmezettben milliszekundumokat használ, nem másodperceket — ha a timestamp a szervertől másodpercekben érkezett, meg kell szorozni 1000-rel, mielőtt a szabvány konstruktoroknak adjuk át.

Konvertálás a felhasználó időzónájával

Az Unix Timestamp egyik fő előnye a helytől való függetlenség. A szerver mindig UTC-ben adja vissza a timestamp-et, a lokális dátummá és idővé alakítás az ügyfél oldalán történik. Kotlin-ban ehhez ZonedDateTime-t használnak a megfelelő ZoneId-val — rendszer által vagy a felhasználó által választott. Ha az alkalmazás különbözō zónákban mutatja az időt (például utazók számára), a timestamp kiküszöböli az idōzóna szervertől való elküldésének szükségességét — egyetlen idōbélyeg elegendő.

// Konvertálás a felhasználó időzónájával
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))
}

// Példa: timestamp = 1720000000, zóna = Europe/Moscow
val result = formatTimestamp(1720000000, ZoneId.of("Europe/Moscow"))

A 2038-as év problémája

A 2038-as év problémája (Year 2038 Problem, Y2K38) — a 32-bites előjeles egész szám alapvető korlátozása az Unix Timestamp tárolására. A 32-bites signed int maximális értéke 2 147 483 647, ami 2038. január 19. 03:14:07 UTC-nek felel meg. E dátum után az érték túlcsordul és negatív számmá válik, ami meghibásodásokat okoz a 32-bites time_t-t használó rendszerekben. A probléma hasonlít a híres Y2K-hez, de elsősorban a beágyazott rendszereket, a régebbi Android verziókat és a 32-bites architektúrájú IoT eszközöket érinti.

A probléma mérete

A Linux Foundation (2025) szerint a Linux eszközök kb. 15%-a az ipari és IoT szegmensben még mindig 32-bites fordításokat használ. Az Android eszközök esetében a kockázat alacsonyabb — a modern okostelefonok többsége 64-bites processzorokon (ARM64) működik, de az Android 4.x és alacsonyabb verziójú régebbi modellek 32-bites time_t-t használhatnak. A probléma megoldása — áttérés 64-bites time_t-re, amely 292 milliárd évig biztonságos. Android 5.0-tól (API 21) kezdve minden eszköz 64-bites időt használ kernel szinten. A mobilalkalmazás-fejlesztőknek elég a timestamp-et Long (64-bites) típusban tárolniuk a probléma elkerüléséhez alkalmazási szinten.

Munka Unix Timestamp-pel Androidban

Az Android fejlesztésben a Unix Timestamp-pel való helyes munka kritikus fontosságú az adatok szinkronizálásához, az üzenetek fogadási idejének megjelenítéséhez, az időkorlátok kiszámításához és az értesítések ütemezéséhez. A System.currentTimeMillis() rendszerhívás az aktuális időt adja vissza milliszekundumokban az Unix korszak óta — ez a legpontosabb idōforrás, amely az eszközön rendelkezésre áll. Hálózati kérésekhez általában az Unix Timestamp másodpercekben használatos, mivel a legtöbb REST API és adatbázis pontosan másodpercekkel dolgozik.

Ajánlott gyakorlatok

Soha ne használja a System.currentTimeMillis()-t intervallumok mérésére — ehhez a System.nanoTime() létezik, amely monoton és nem függ a felhasználó óraállításaitól. Az idō megjelenítéséhez mindig tárolja a timestamp-et UTC-ben és alakítsa át a lokális idōzónára a felhasználói felület oldalán. Adatbázisokkal (SQLite, Room) való munka során használja az INTEGER típust és tárolja a timestamp-et másodpercekben — ez 8 bájtot (Long) foglal el és támogatja a natív SQL rendezést. JSON szerializációhoz ajánlott a timestamp elküldése számként (Long), nem karakterláncként — ez kompaktabb és gyorsabban elemezhető.

// Végrehajtási idő helyes mérése
val start = System.nanoTime()
// ... művelet ...
val elapsed = System.nanoTime() - start
val seconds = elapsed / 1_000_000_000.0

// Tárolás Room-ban (Entity)
@Entity
data class Message(
    @PrimaryKey val id: Long,
    val text: String,
    val createdAt: Long // Unix Timestamp másodpercekben
)

Idő feldolgozása a szervertől

A Unix Timestamp szervertől való fogadásakor mindig ellenőrizze a mérési egységet: egyes API-k milliszekundumokat adnak vissza (JavaScript-kompatibilis), mások másodperceket (POSIX szabvány). Az egységekről szóló megállapodást rögzíteni kell az API dokumentációjában. A szerver válaszában a timestamp elküldhető Long (JSON szám) vagy String (ISO 8601) formában. Hibakereséshez adjon hozzá egy segédfüggvényt, amely a timestamp-et ember által olvasható formátumban jeleníti meg — ez egyszerűsíti az idōbélyegek helyességének ellenőrzését a fejlesztés során.

Időbélyegek tárolása adatbázisokban

Az adatbázisban történő idōtárolási formátum választása közvetlenül befolyásolja a lekérdezések teljesítményét, a kód összetettségét és az idōzónákkal való munka helyességét. Unix Timestamp — a leghatékonyabb formátum a relációs adatbázisok számára: egész számként tárolódik (4 vagy 8 bájt), támogatja az indexelést és a gyors rendezést. Az ISO 8601 karakterláncokkal ellentétben a timestamp nem igényel elemzést rendezéskor és kevesebb helyet foglal az indexben. Room és SQLite esetében ajánlott a timestamp tárolása INTEGER típusban és index használata az idō oszlopon.

Ajánlások mobil projektekhez

A Room könyvtárat használó Android alkalmazások esetében ajánlott a timestamp tárolása Long (64-bites) ként és TypeConverter használata az automatikus átalakításhoz Long és Date vagy Instant között. Az adatbázis lekérdezésekben használja az összehasonlító operátorokat (>, <, BETWEEN) — ezek natívan működnek a numerikus típusokkal. Az idō szerinti rendezést igénylő adatok gyorsítótárához (például üzenetlista) kötelezően hozzon létre indexet a timestamp oszlopon — ez több nagyságrenddel gyorsítja az ORDER BY lekérdezéseket nagy adatmennyiség esetén.