Porozumění časovým zónám, UTC a unixovým časovým razítkům

Čas se zdá jednoduchý, dokud se nepokusíte napsat software, který ho správně zpracovává. Událost naplánovaná na „15:00" znamená různé věci v Tokiu, Londýně a New Yorku. Letní čas posunuje hodiny dopředu nebo dozadu — ale ne všude a ne ve stejných termínech. Časové razítko, které vypadá správně ve vašem lokálním prostředí, se rozbije na produkci, protože server je v jiné zóně.

Časové zóny jsou jedním z nejspolehlivěji matoucích témat ve vývoji softwaru. Tento článek vysvětluje, jak fungují, odkud pochází složitost a jak se vyhnout nejčastějším chybám.

Proč časové zóny existují

Země se otáčí o 360 stupňů za 24 hodin, což znamená, že slunce je v nejvyšším bodě v různých okamžicích v závislosti na vaší zeměpisné délce. Před 19. stoletím každé město nastavovalo hodiny podle místního slunečního času — poledne bylo, když slunce bylo nejvýše. To fungovalo dobře, dokud železnice nepropojily vzdálená města a jízdní řád vlaků nepotřeboval jednotné hodiny.

V roce 1884 se delegáti z 25 zemí sešli na Mezinárodní konferenci o poledníku ve Washingtonu a dohodli se na rozdělení světa do 24 standardních časových zón, každá posunutá od nultého poledníku (0 stupňů zeměpisné délky) procházejícího Greenwichem v Anglii.

V praxi hranice časových zón sledují politické hranice, nikoli úhledné poledníkové linie. Čína pokrývá pět geografických zón, ale používá jediný oficiální čas (UTC+8). Indie používá UTC+5:30 — půlhodinový posun. Nepál používá UTC+5:45. Skutečná mapa časových zón je chaotická.

UTC vs. GMT

GMT (Greenwich Mean Time) je střední sluneční čas v Královské observatoři v Greenwichi. Byl světovým časovým referentem více než století.

UTC (Coordinated Universal Time) nahradil GMT jako mezinárodní standard v roce 1972. UTC je založen na atomových hodinách místo astronomických pozorování, což ho činí daleko přesnějším. Pro většinu praktických účelů UTC a GMT ukazují stejný čas, ale UTC je správný technický referent.

Letní čas: organizovaný chaos

Přibližně 70 zemí dodržuje letní čas (DST), posouvající hodiny o hodinu dopředu na jaře a zpět na podzim. Záměrem je sladit bdělé hodiny s denním světlem. Výsledkem je pololetní zdroj chyb.

Klíčové komplikace:

• Není univerzální. Většina Afriky, Asie a Jižní Ameriky letní čas nedodržuje. V USA se ho Arizona a Havaj neúčastní.
• Různá data. EU posouvá hodiny poslední neděli v březnu a říjnu. USA posouvá druhou neděli v březnu a první neděli v listopadu. Několik týdnů ročně nejsou synchronizovány.
• Nejednoznačné časy. Když se hodiny vrátí zpět, hodina od 1:00 do 2:00 nastane dvakrát. Časové razítko „1:30" v ten den je nejednoznačné.
• Přeskočené časy. Když hodiny skočí dopředu, hodina od 2:00 do 3:00 neexistuje. Schůzka naplánovaná na 2:30 v ten den se nikdy neuskuteční.
• Politické změny. Vlády mohou (a mění) pravidla letního času s malým předstihem. Rusko přijalo trvalý letní čas v roce 2011, pak v roce 2014 přešlo na trvalý standardní čas. Maroko změnilo pravidla letního času několikrát.

ISO 8601: univerzální formát data

Aby se předešlo nejednoznačnosti, mezinárodní standard ISO 8601 definuje jasný formát data a času:

2026-03-29T14:30:00Z
2026-03-29T14:30:00+02:00
2026-03-29T14:30:00-05:00

• T odděluje datum od času.
• Z znamená UTC (časová zóna „Zulu" ve vojenské terminologii).
• +02:00 nebo -05:00 je posun od UTC.

Tento formát je jednoznačný, řaditelný jako prostý text a univerzálně srozumitelný knihovnami pro parsování dat. V případě pochybností použijte ISO 8601.

Unixová časová razítka

Unixové časové razítko (také nazývané epochový čas nebo POSIX čas) je počet sekund, které uplynuly od 1. ledna 1970, 00:00:00 UTC — okamžiku známého jako unixová epocha.

Unixová časová razítka nemají časovou zónu — jsou vždy v UTC. To je činí ideálními pro ukládání a porovnávání časů v softwaru. Do místní časové zóny konvertujete pouze na prezentační vrstvě.

Databáze časových zón IANA

Software nepotřebuje jen UTC posuny — potřebuje znát úplnou historii a budoucí pravidla pro každý region, včetně přechodů letního času, politických změn a historických anomálií. Tyto informace se nacházejí v databázi časových zón IANA (nazývané také Olsonova databáze nebo tzdata).

Používá identifikátory jako America/New_York, Europe/Paris, Asia/Tokyo. Každý záznam kóduje kompletní historii UTC posunů a pravidel letního času pro danou lokaci.

Proto byste nikdy neměli ukládat časovou zónu jako pevný posun jako „+02:00". Posun říká aktuální rozdíl od UTC, ale nic neříká o pravidlech letního času. Europe/Paris je UTC+1 v zimě a UTC+2 v létě. IANA identifikátor zachycuje obojí.

Běžné chyby v softwaru

1. Ukládání místního času bez časové zóny. Hodnota jako 2026-03-29 14:30:00 je bezesmyslná bez znalosti, ke které časové zóně se vztahuje. Vždy ukládejte UTC nebo zahrňte posun.
2. Předpokládání, že UTC posun se rovná časové zóně. UTC+2 v březnu může být UTC+3 v červenci (pokud region dodržuje letní čas). Ukládejte IANA identifikátor, ne posun.
3. Ignorování přechodů letního času při plánování. Denní úloha ve 2:30 bude jednou ročně přeskočena a jednou ročně spuštěna dvakrát, pokud letní čas neošetříte.
4. Předpokládání, že dny mají 24 hodin. V dnech přechodu letního času má den 23 nebo 25 hodin. Výpočet „zítra ve stejný čas" přičtením 86 400 sekund bude o hodinu špatně.
5. Naivní používání JavaScript Date. new Date("2026-03-29") je v některých enginech parsováno jako UTC a v jiných jako místní čas. Vždy buďte explicitní ohledně časové zóny.

Nejlepší postupy pro vývojáře

• Ukládejte časy v UTC. Konvertujte do místní časové zóny uživatele pouze na prezentační vrstvě.
• Používejte IANA identifikátory časových zón (America/New_York), ne pevné posuny (-05:00).
• Používejte ISO 8601 pro serializaci. Je jednoznačný a univerzálně parsovatelný.
• Používejte vyspělou datovou knihovnu. V JavaScriptu použijte Intl.DateTimeFormat nebo knihovnu jako date-fns-tz. V Pythonu použijte zoneinfo (3.9+) nebo pytz. V Javě použijte java.time.ZonedDateTime.
• Udržujte tzdata aktuální. Vlády mění pravidla letního času. Váš operační systém a běhové prostředí jazyka potřebují aktuální data o časových zónách.
• Testujte s více časovými zónami. Nepředpokládejte, že váš server a vaši uživatelé sdílejí stejnou zónu.

Další informace

Čas je klamavě složitý, ale pravidla jsou dobře zdokumentována a nástroje vyspělé. Klíčem je respektovat složitost místo předpokládání, že neexistuje.

• Cron výrazy vysvětleny — plánování úloh napříč časovými zónami
• Generátor hašů a Tester regex — další vývojářské nástroje na ToolK