Unix Timestamp: co to je, konverze a ukládání v mobilním vývoji

Co je Unix Timestamp?

Unix Timestamp (také známý jako POSIX time, Epoch time nebo Unix time) — je systém měření času, který určuje počet sekund, které uplynuly od 1. ledna 1970 00:00:00 UTC (éra Unixu). Toto datum bylo vybráno jako začátek počítání pro operační systém Unix a následně se formát stal de facto standardem pro reprezentaci času v počítačových systémech. Timestamp nezohledňuje přestupné sekundy — každá minuta se počítá jako 60 sekund, i když Mezinárodní služba rotace Země občas přidává dodatečnou sekundu pro korekci atomového času.

Éra Unixu: proč rok 1970?

Výběr 1. ledna 1970 souvisí s historií vývoje operačního systému Unix. Vývojáři Ken Thompson a Dennis Ritchie zvolili toto datum jako jednoduchý a kulatý počáteční bod — bylo dostatečně brzké na to, aby pokrylo všechna možná data, a zároveň dostatečně pozdní na to, aby čas mohl být uložen v 32-bitovém celém čísle se znaménkem. Původně se čas měřil v šedesátinách sekundy, poté v ticích (1/60 sekundy) a teprve v sedmém vydání Unixu (V7, 1979) se formát stabilizoval jako celý počet sekund. Podle The Open Group Base Specifications (Issue 8, 2024) jsou systémy kompatibilní s POSIX povinny tento formát podporovat.

Jak funguje Unix Timestamp

Princip fungování Unix Timestamp je založen na jednoduchém počítadle: každý uplynulý den přidává k hodnotě 86 400 sekund. Například timestamp 1 720 000 000 odpovídá datu v polovině roku 2024 — přesný převod lze provést vydělením počtem sekund ve dni, hodině a minutě. Takový přístup činí timestamp ideálním pro strojové ukládání: je to celé číslo zabírající 4 bajty (32-bitový int) nebo 8 bajtů (64-bitový long) a podporuje přímé porovnání — větší timestamp = pozdější datum.

Matematika převodu

Jeden den = 86 400 sekund (24 x 60 x 60). Jedna hodina = 3600 sekund. Pro převod timestampu na datum je třeba postupně vypočítat počet dní, hodin, minut a sekund od začátku éry. Obrácený převod — převeďte datum na dny od 1970-01-01, poté vynásobte 86 400 a přidejte posun vůči UTC. V Javě a Kotlinu jsou tyto výpočty již implementovány ve standardních třídách java.time.Instant a java.util.Date, což zbavuje vývojáře ručních výpočtů.

        // Získejte Unix Timestamp v sekundách
val seconds = System.currentTimeMillis() / 1000

// Převeďte timestamp na datum pomocí java.time
val instant = Instant.ofEpochSecond(seconds)
val localDate = instant.atZone(ZoneId.of("Europe/Moscow")).toLocalDate()

// Obráceně: datum na timestamp
val date = LocalDate.of(2026, 7, 21)
val ts = date.atStartOfDay(ZoneOffset.UTC).toEpochSecond()

Převod Unix Timestamp na datum a zpět

Převod Unix Timestamp na čas čitelný pro člověka je jednou z nejčastějších operací v mobilním vývoji. V Androidu je k dispozici několik způsobů převodu v závislosti na minimální verzi API: pro API 26+ se doporučuje java.time.Instant, pro starší verze se používá java.util.Date a java.text.SimpleDateFormat. Je důležité si zapamatovat, že Android a JVM standardně používají milisekundy, nikoli sekundy — pokud byl timestamp přijat ze serveru v sekundách, je třeba jej vynásobit 1000 před předáním standardním konstruktorům.

Převod s časovým pásmem uživatele

Jednou z hlavních výhod Unix Timestamp je nezávislost na lokalitě. Server vždy vrací timestamp v UTC a převod na místní datum a čas se provádí na straně klienta. V Kotlinu se k tomu používá ZonedDateTime s příslušným ZoneId — systémovým nebo zvoleným uživatelem. Pokud aplikace zobrazuje čas v různých pásmech (například pro cestovatele), timestamp odstraňuje potřebu předávat časové pásmo ze serveru — stačí jedno časové razítko.

// Převod s časovým pásmem uživatele
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říklad: timestamp = 1720000000, pásmo = Europe/Moscow
val result = formatTimestamp(1720000000, ZoneId.of("Europe/Moscow"))

Problém roku 2038

Problém roku 2038 (Year 2038 Problem, Y2K38) — je základní omezení 32-bitového celého čísla se znaménkem pro ukládání Unix Timestamp. Maximální hodnota 32-bitového signed int je 2 147 483 647, což odpovídá 19. lednu 2038 v 03:14:07 UTC. Po tomto datu hodnota přeteče a změní se na záporné číslo, což způsobí selhání v systémech používajících 32-bitový time_t. Problém je podobný známému Y2K, ale postihuje především vestavěné systémy, starší verze Androidu a IoT zařízení s 32-bitovou architekturou.

Rozsah problému

Podle Linux Foundation (2025) asi 15% zařízení s Linuxem v průmyslovém a IoT segmentu stále používá 32-bitové kompilace. Pro zařízení Android je riziko nižší — většina moderních chytrých telefonů běží na 64-bitových procesorech (ARM64), ale starší modely s Androidem 4.x a nižším mohou používat 32-bitový time_t. Řešením problému je migrace na 64-bitový time_t, který je bezpečný po dobu 292 miliard let. Počínaje Androidem 5.0 (API 21) všechna zařízení používají 64-bitový čas na úrovni jádra. Vývojářům mobilních aplikací stačí ukládat timestamp v typu Long (64-bitový), aby se problému vyhnuli na úrovni aplikace.

Práce s Unix Timestamp v Androidu

V Android vývoji je správná práce s Unix Timestamp kritická pro synchronizaci dat, zobrazení času přijetí zpráv, výpočet časových limitů a plánování oznámení. Systémové volání System.currentTimeMillis() vrací aktuální čas v milisekundách od éry Unixu — to je nejpřesnější zdroj času dostupný na zařízení. Pro síťové požadavky se obvykle používá Unix Timestamp v sekundách, protože většina REST API a databází pracuje právě se sekundami.

Doporučené postupy

Nikdy nepoužívejte System.currentTimeMillis() pro měření intervalů — k tomu slouží System.nanoTime(), která je monotónní a nezávisí na změnách hodin uživatelem. Pro zobrazení času vždy ukládejte timestamp v UTC a převádějte jej do místního časového pásma na straně uživatelského rozhraní. Při práci s databázemi (SQLite, Room) používejte typ INTEGER a ukládejte timestamp v sekundách — to zabírá 8 bajtů (Long) a podporuje nativní SQL třídění. Pro serializaci v JSON se doporučuje odesílat timestamp jako číslo (Long), nikoli jako řetězec — je to kompaktnější a rychleji se parsuje.

// Správné měření doby provádění
val start = System.nanoTime()
// ... operace ...
val elapsed = System.nanoTime() - start
val seconds = elapsed / 1_000_000_000.0

// Uložte v Room (Entity)
@Entity
data class Message(
    @PrimaryKey val id: Long,
    val text: String,
    val createdAt: Long // Unix Timestamp v sekundách
)

Zpracování času ze serveru

Při příjmu Unix Timestamp ze serveru vždy zkontrolujte jednotku měření: některá API vracejí milisekundy (kompatibilní s JavaScriptem), jiná sekundy (standard POSIX). Dohoda o jednotkách musí být zaznamenána v dokumentaci API. V odpovědi serveru může být timestamp předán jako Long (číslo JSON) nebo String (ISO 8601). Pro ladění přidejte pomocnou funkci, která zobrazuje timestamp v čitelném formátu — to zjednodušuje kontrolu správnosti časových razítek během vývoje.

Ukládání časových razítek v databázích

Výběr formátu ukládání času v databázi přímo ovlivňuje výkon dotazů, složitost kódu a správnost práce s časovými pásmy. Unix Timestamp — nejúčinnější formát pro relační databáze: ukládá se jako celé číslo (4 nebo 8 bajtů), podporuje indexování a rychlé třídění. Na rozdíl od řetězců ISO 8601 timestamp nevyžaduje parsování při třídění a zabírá méně místa v indexu. Pro Room a SQLite se doporučuje ukládat timestamp v typu INTEGER a používat index na sloupci času.

Doporučení pro mobilní projekty

Pro Android aplikace s knihovnou Room se doporučuje ukládat timestamp jako Long (64-bitový) a používat TypeConverter pro automatický převod mezi Long a Date nebo Instant. Při dotazech do databáze používejte porovnávací operátory (>, <, BETWEEN) — ty pracují nativně s číselnými typy. Pro ukládání do mezipaměti dat, která vyžadují třídění podle času (například seznam zpráv), vytvořte povinně index na sloupci timestamp — to urychlí dotazy s ORDER BY o několik řádů při velkém objemu dat.