Převaděč Unix Timestamp

Převeďte libovolný Unix timestamp na lidsky čitelné datum a čas.

Náš převodník:

• automaticky detekuje sekundy (10 míst) a milisekundy (13 míst)
• zobrazuje UTC a místní čas
• zobrazuje několik formátů včetně ISO 8601 a RFC 2822

Převeďte libovolné datum a čas na Unix timestamp.

Vyberte datum, zvolte své časové pásmo a získejte epocha čas v sekundách i milisekundách.

Ideální pro:

• vývoj API
• dotazy do databáze
• ladění problémů souvisejících s časem

Unixový čas je systém pro sledování časového okamžiku jako počtu sekund, které uplynuly od unixové epochy, definované jako 00:00:00 UTC 1. ledna 1970. IEEE a The Open Group tento koncept kodifikují ve standardu POSIX (IEEE Std 1003.1), kde se oficiálně nazývá „Seconds Since the Epoch“.

Klíčovou nuancí zdokumentovanou v POSIXu je, že unixový čas záměrně ignoruje přestupné sekundy, takže každý den je považován za přesně 86 400 sekund. Protože hodnota je jediné celé číslo nezávislé na časových pásmech, je jednoznačná napříč systémy.

Ukládání času jako celého čísla, jak uvádí MDN Web Docs pro objekt Date v JavaScriptu, usnadňuje aritmetiku a porovnávání ve srovnání s parsováním formátovaných textových řetězců dat.

10místný Unix timestamp počítá sekundy od epochy, zatímco 13místný timestamp počítá milisekundy, a jejich zaměňování je nejčastější chybou při převodu.

Podle MDN Web Docs vrací funkce Date.now() a getTime() v JavaScriptu milisekundy, takže 1700000000000 je platná hodnota pro JS. Naproti tomu funkce POSIX C jako time() a Pythonova time.time(), spolu s většinou SQL databází a příkazem Bash date +%s, pracují v sekundách (1700000000).

Pro převod mezi nimi vynásobte sekundy 1 000 nebo vydělte milisekundy 1 000.

Náš převodník automaticky detekuje jednotku podle počtu míst, ale při psaní kódu byste měli vždy ověřit, jakou jednotku vaše jazyková platforma nebo API očekává, abyste se vyhnuli datům spadajícím do roku 1970 nebo tisíce let do budoucnosti.

Aktuální Unix timestamp můžete vygenerovat jediným voláním téměř v každém programovacím jazyce.

• V JavaScriptu doporučuje MDN Web Docs Math.floor(Date.now() / 1000) pro sekundy nebo Date.now() pro milisekundy.
• V Pythonu vrací time.time() desetinné číslo představující sekundy od epochy, což odpovídá funkci time() z knihovny C definované POSIXem.
• V příkazové řádce vypíše date +%s z balíčku GNU coreutils aktuální timestamp s přesností na sekundy, zatímco PHP používá time() a Go používá time.Now().Unix().
• SQL enginy zpřístupňují funkce jako UNIX_TIMESTAMP() v MySQL a EXTRACT(EPOCH FROM now()) v PostgreSQL.

Všechny tyto možnosti odkazují na stejný počátek v roce 1970 v UTC, takže hodnoty jsou přímo zaměnitelné, jakmile normalizujete jednotku sekund oproti milisekundám.

Použijte Unix timestamp pro ukládání a aritmetické operace a ISO 8601 pro čitelnou výměnu dat a logy.

ISO 8601 je mezinárodní standard pro reprezentaci dat a časů ve formě řetězců jako 2023-11-14T22:13:20Z, kde velké písmeno T odděluje datum od času a koncové Z označuje UTC (Zulu time). Tato písmena rozlišují velká a malá písmena, takže pokud upravujete řetězce z různých zdrojů, rychlý průchod přes převodník velikosti písmen zajistí jejich snadné parsování. Standard IETF RFC 3339 upravuje ISO 8601 pro použití na internetu a je to formát, který většina JSON API přebírá pro pole dat, protože samotný JSON (RFC 8259) žádný nativní datový typ nemá.

Unixové celé číslo je kompaktnější a nezávislé na lokalizaci, ale samo o sobě nic nevypovídá, zatímco řetězec ISO 8601 je okamžitě čitelný. Mnoho systémů ukládá celé číslo interně a na hranici API ho serializuje do ISO 8601, aby získalo výhody obou přístupů.

Unix timestamp nemá žádné časové pásmo, protože vždy odkazuje na jediný okamžik měřený od epochy v UTC. Časová pásma hrají roli pouze tehdy, když tento okamžik vykreslujete jako datum na hodinách pro konkrétního uživatele.

Databáze časových pásem IANA (tz database) je autoritativním zdrojem, který operační systémy a programovací jazyky používají k mapování okamžiku na místní čas, včetně historických pravidel pro letní čas.

Osvědčeným postupem, který zmiňují MDN Web Docs a nespočet inženýrských příruček, je ukládat a přenášet timestampy v UTC a na místní čas diváka je převádět až v okamžiku zobrazení. Tím se eliminuje nejednotnost ohledně změn letního času a porovnávání napříč regiony je spolehlivé a reprodukovatelné.

Problém roku 2038 představuje okamžik, kdy 32bitová znaménková celá čísla uchovávající unixový čas přetečou; to nastane 19. ledna 2038 v 03:14:07 UTC.

Maximální hodnota znaménkové 32bitové hodnoty je 2 147 483 647 sekund; o sekundu později se přetočí na velké záporné číslo, které naivní kód interpretuje jako prosinec 1901. To připomíná historické obavy kolem problému roku 2000, ale kořeny to má v pevné šířce typu time_t v jazyce C na starších platformách.

Moderní operační systémy a programovací jazyky z větší části přešly na 64bitový time_t, čímž se přetečení posunulo zhruba o 292 miliard let do budoucnosti. Hlavní rizikovou oblastí, kterou by vývojáři měli zkontrolovat, zůstávají vestavěné systémy a staré formáty souborů.

Unixová časová razítka tvoří páteř práce s časem v backendových systémech, logovcích a API, protože se řadí, odlišují a porovnávají jako obyčejná celá čísla.

Databáze ukládají sloupce created_at a updated_at jako hodnoty epochy nebo z nich odvozené typy časových razítek a vrstvy mezipaměti využívají časová razítka vypršení platnosti k zneplatnění záznamů. Spoléhají na ně i bezpečnostní tokeny: standard JWT, RFC 7519, definuje nároky exp (vypršení platnosti) a iat (vydáno v) jako hodnoty NumericDate, což jsou doslova sekundy od unixové epochy.

Distribuované logy a streamy událostí používají časová razítka k určení pořadí a nástroje pro omezování rychlosti (rate limitery) porovnávají aktuální epochu s uloženými okny. Díky tomu, že jsou nezávislá na jazyku, se skvěle hodí pro předávání času napříč hranicemi služeb.

Záporná unixová časová razítka představují okamžiky před epochou, takže -86400 odpovídá 31. prosinci 1969 v 00:00:00 UTC. Definice POSIX umožňuje, aby byl počet sekund záporný, a jazyky jako JavaScript to respektují: dokumentace MDN Web Docs uvádí, že objekt Date akceptuje záporné hodnoty v milisekundách pro vyjádření dat před rokem 1970.

To se hodí pro historická data, data narození nebo archivní záznamy.

Dejte si však pozor, že některé starší systémy, databáze a 32bitové nástroje považují unixový čas za bezznaménkový nebo odmítají záporný vstup, přičemž hodnotu potichu oříznou na epochu nebo vyvolají chybu. Při zpracování historických dat ověřte, zda každá vrstva vašeho zásobníku, od typu databázového sloupce až po klientskou knihovnu, podporuje časová razítka se znaménkem.

• Nejčastější chybou je záměna sekund a milisekund, což vede k datům vzdáleným o desítky let nebo zaseknutým v roce 1970. Před převodem si vždy ověřte, jakou jednotku zdroj používá, protože JavaScript vrací milisekundy, zatímco většina backendů vrací sekundy.
• Druhým úskalím je předpoklad, že časové razítko nese časové pásmo; nenese, takže dvojnásobné použití místního posunu vede k nesprávným časům na hodinách.
• Mezi další patří ignorování limitu roku 2038 u 32bitových polí a očekávání, že unixový čas zohlední přestupné sekundy, což standard POSIX výslovně vylučuje.
• Nakonec se vyvarujte ručnímu parsování zformátovaných řetězců dat; používejte standardní knihovny a pro výměnu dávejte přednost formátu ISO 8601 (RFC 3339), jak doporučují MDN Web Docs, abyste se vyhnuli nejednoznačným formátům jako MM/DD versus DD/MM.