Az idő egyszerűnek tűnik, amíg nem próbálsz meg szoftvert írni, amely helyesen kezeli. Egy „délután 3-ra" tervezett esemény mást jelent Tokióban, Londonban és New Yorkban. A nyári időszámítás előre- vagy hátraállítja az órákat — de nem mindenhol, és nem ugyanazokon a dátumokon. Egy időbélyeg, amely helyesnek tűnik a helyi környezetedben, hibát okoz éles környezetben, mert a szerver másik időzónában van.
Az időzónák a szoftverfejlesztés egyik legmegbízhatóbban zavaros témája. Ez a cikk elmagyarázza, hogyan működnek, honnan ered a bonyolultság, és hogyan kerülheted el a leggyakoribb hibákat.
Miért léteznek időzónák
A Föld 24 óra alatt forog 360 fokot, ami azt jelenti, hogy a Nap különböző pillanatokban van a legmagasabb pontján a hosszúsági fokodtól függően. A 19. század előtt minden város a helyi napidő szerint állította az óráit — dél volt, amikor a Nap az égen a legmagasabb volt. Ez jól működött, amíg a vasútak össze nem kötötték a távoli városokat, és a menetrendnek egyetlen, konzisztens órára volt szüksége.
1884-ben 25 nemzet küldöttei találkoztak a Nemzetközi Meridián Konferencián Washington D.C.-ben, és megállapodtak, hogy a világot 24 szabványos időzónára osztják, amelyek mindegyike az alapmeridiántól (0 fok hosszúság), Greenwich-en, Anglián áthaladva van eltolva.
A gyakorlatban az időzóna-határok politikai határokat követnek, nem rendezett hosszúsági vonalakat. Kína öt földrajzi zónát ölel fel, de egyetlen hivatalos időt használ (UTC+8). India UTC+5:30-at használ — félórás eltolás. Nepál UTC+5:45-öt. Az időzónák valós térképe kaotikus.
UTC vs. GMT
A GMT (Greenwich-i középidő) a greenwichi Királyi Csillagvizsgálóban mért átlagos napidő. Több mint egy évszázadon át a világ időreferenciája volt.
Az UTC (Koordinált Világidő) 1972-ben váltotta fel a GMT-t mint nemzetközi szabvány. Az UTC atomórákon alapul, nem csillagászati megfigyelésen, így sokkal pontosabb. A legtöbb gyakorlati célra az UTC és a GMT ugyanazt az időt mutatja, de az UTC a helyes technikai hivatkozás.
Miért „UTC" és nem „KVI"? A rövidítés kompromisszum az angol „Coordinated Universal Time" (CUT) és a francia „Temps Universel Coordonné" (TUC) között. Egyik fél sem kapta meg a preferált rövidítését, ezért az UTC-t választották nyelvsemleges alternatívaként.
Nyári időszámítás: szervezett káosz
Körülbelül 70 ország tartja be a nyári időszámítást (DST), tavasszal egy órával előre, ősszel visszaállítva az órákat. A cél a felébredési idő és a napfény összehangolása. Az eredmény a hibák féléves forrása.
Fő komplikációk:
- Nem univerzális. Afrika, Ázsia és Dél-Amerika nagy része nem tartja be a nyári időszámítást. Az Egyesült Államokban Arizona és Hawaii kimarad.
- Eltérő dátumok. Az EU március és október utolsó vasárnapján vált. Az USA március második és november első vasárnapján. Évente több hétig nincsenek szinkronban.
- Kétértelmű időpontok. Amikor az órákat visszaállítják, az 1:00-tól 2:00-ig tartó óra kétszer fordul elő. Az adott napon az „1:30" időbélyeg kétértelmű.
- Kihagyott időpontok. Amikor az órákat előreállítják, a 2:00-tól 3:00-ig tartó óra nem létezik. Az adott napra 2:30-ra tervezett megbeszélés soha nem történik meg.
- Politikai változások. A kormányok rövid értesítéssel változtathatják (és változtatják is) a nyári időszámítás szabályait. Oroszország 2011-ben állandó nyári időszámítást vezetett be, majd 2014-ben állandó téli időre váltott. Marokkó többször változtatott a DST szabályokon.
ISO 8601: az univerzális dátumformátum
A félreérthetőség elkerülése érdekében az ISO 8601 nemzetközi szabvány egy egyértelmű dátum- és időformátumot határoz meg:
2026-03-29T14:30:00Z
2026-03-29T14:30:00+02:00
2026-03-29T14:30:00-05:00
- A
Tválasztja el a dátumot az időtől. - A
ZUTC-t jelent (a katonai terminológiában „Zulu" időzóna). - A
+02:00vagy-05:00az UTC-eltolás.
Ez a formátum egyértelmű, egyszerű szövegként rendezhető, és univerzálisan értelmezett a dátumfeldolgozó könyvtárak által. Ha kétséged van, használd az ISO 8601-et.
Unix időbélyeg
A Unix időbélyeg (más néven epoch idő vagy POSIX idő) az 1970. január 1., 00:00:00 UTC — az úgynevezett Unix epoch — óta eltelt másodpercek száma.
| Ember által olvasható | Unix időbélyeg |
|---|---|
| 1970-01-01 00:00:00 UTC | 0 |
| 2000-01-01 00:00:00 UTC | 946684800 |
| 2026-03-29 12:00:00 UTC | 1774987200 |
A Unix időbélyegnek nincs időzónája — mindig UTC-ben van. Ez ideálissá teszi az idők tárolásához és összehasonlításához szoftverben. Helyi időzónára csak a megjelenítési rétegben konvertálsz.
A 2038-as probléma: Azok a rendszerek, amelyek a Unix időbélyeget 32 bites előjeles egész számként tárolják, 2038. január 19-én 03:14:07 UTC-kor túlcsordulnak. A maximális érték (2 147 483 647) negatív számba fordul, amelyet 1901 decemberként értelmez. A legtöbb modern rendszer 64 bites egész számokat használ, amelyek nem csordulnak túl még 292 milliárd évig.
Az IANA időzóna-adatbázis
A szoftvernek nem csak UTC-eltolásokra van szüksége — tudnia kell az egyes régiók teljes múltbeli és jövőbeli szabályait, beleértve a DST-váltásokat, politikai változásokat és történelmi anomáliákat. Ez az információ az IANA Időzóna-adatbázisban (más néven Olson adatbázis vagy tzdata) található.
Azonosítókat használ, mint America/New_York, Europe/Paris, Asia/Tokyo. Minden bejegyzés tartalmazza az adott hely UTC-eltolásainak és DST-szabályainak teljes történetét.
Ezért soha ne tárold az időzónát fix eltolásként, mint „+02:00". Az eltolás megmondja az UTC-től való aktuális különbséget, de semmit nem árul el a DST-szabályokról. Az Europe/Paris télen UTC+1, nyáron UTC+2. Az IANA-azonosító mindkettőt tartalmazza.
Gyakori hibák szoftverben
- Helyi idő tárolása időzóna nélkül. Egy olyan érték, mint
2026-03-29 14:30:00, értelmezhetetlen anélkül, hogy tudnánk, melyik időzónára vonatkozik. Mindig UTC-ben tárold, vagy add meg az eltolást. - Feltételezni, hogy az UTC-eltolás egyenlő az időzónával. Márciusban az UTC+2 júliusban UTC+3 lehet (ha a régió betartja a DST-t). Tárold az IANA-azonosítót, ne az eltolást.
- A DST-váltások figyelmen kívül hagyása ütemezésnél. Egy 2:30-ra ütemezett napi feladat évente egyszer kimarad és évente egyszer kétszer fut le, ha nem kezeled a DST-t.
- Feltételezni, hogy a napok 24 órásak. A DST-váltás napjain egy nap 23 vagy 25 órás. Ha „holnap ugyanebben az időben"-t 86 400 másodperc hozzáadásával számolsz, egy órát fogsz tévedni.
- A JavaScript
Datenaiv használata. Anew Date("2026-03-29")-et egyes motorok UTC-ként, mások helyi időként értelmezik. Mindig legyél egyértelmű az időzónával.
Legjobb gyakorlatok fejlesztőknek
- Tárold az időket UTC-ben. Csak a megjelenítési rétegben konvertálj a felhasználó helyi időzónájára.
- Használj IANA időzóna-azonosítókat (
America/New_York), ne fix eltolásokat (-05:00). - Használd az ISO 8601-et a szerializáláshoz. Egyértelmű és univerzálisan értelmezhető.
- Használj érett dátumkönyvtárat. JavaScriptben használd az
Intl.DateTimeFormat-ot vagy egy könyvtárat, mint adate-fns-tz. Pythonban azoneinfo-t (3.9+) vagy apytz-t. Javában ajava.time.ZonedDateTime-ot. - Tartsd naprakészen a
tzdata-t. A kormányok változtatják a DST-szabályokat. Az operációs rendszerednek és a nyelvi futtatókörnyezetednek aktuális időzóna-adatokra van szüksége. - Tesztelj több időzónával. Ne feltételezd, hogy a szervered és a felhasználóid ugyanabban a zónában vannak.
Tovább
Az idő megtévesztően összetett, de a szabályok jól dokumentáltak és az eszközök érettre fejlődtek. A kulcs a bonyolultság tiszteletben tartása, nem pedig annak figyelmen kívül hagyása.
- A Cron kifejezések demisztifikálása — feladatütemezés időzónákon keresztül
- Hash generátor és Regex tesztelő — további fejlesztői eszközök a ToolK-on