Amikor egy hír megjelenik egy weboldalon, a mögötte álló szerver egy adott pillanatot rögzít — de ez a pillanat nem feltétlenül azt az időt jelenti, amit az olvasó a saját órájáról leolvas. Ez a látszólag apró különbség rendszeresen okoz zavart, félreértést, és néhány esetben komoly technikai leállást is.
Egy közös nyelv: UTC és ISO 8601
A probléma megoldására a technikai világ egy közös, semleges viszonyítási pontot használ: az UTC-t (Coordinated Universal Time). Az UTC nem egyetlen ország helyi ideje, hanem atomórák világméretű hálózatának súlyozott átlagából számított, állandó viszonyítási pont, amely — a helyi időtől eltérően — nem változik a nyári időszámítás miatt. A szerverek, adatbázisok és hálózati protokollok ezért jellemzően UTC-ben tárolják az időpontokat, és csak megjelenítéskor számítják át az olvasó helyi idejére.
Ehhez társul az ISO 8601 nemzetközi szabvány, amely egységes formátumot ad a dátumoknak (például 2026-09-18T14:30:00Z). Ennek az az egyszerű, de fontos előnye, hogy amíg egy dátumot országtól függően többféleképpen is le lehet írni — a 01/05/22 jelentheti január 5-ét vagy május 1-jét is, aszerint, hogy amerikai vagy európai konvenciót követünk —, az ISO-formátum félreérthetetlen, és szövegként rendezve is helyes időrendet ad. Ez lett a de facto csereformátum szoftverek, adatbázisok és API-k között.
Amikor a rendszer elszámolja az órát
A különbség a szerver- és a helyi idő között nemcsak elméleti probléma. 2018-ban Danny Sullivan, a Google akkori keresési kapcsolattartója (Search Liaison), nyilvánosan beszélt egy esetről, amikor egy miami hírportál cikkének dátuma és órája technikailag helyes volt, de az időzóna-jelölése hibás — ennek eredményeként a Google Keresés a cikket 5 órával korábbinak „látta” a valóságosnál. A hiba különösen rosszul jött egy hurrikán idején, amikor a friss és a régi cikkek pontos megkülönböztetése életbevágó lehet.
Öt évvel később, 2017. január 1-jén UTC szerint éjfélkor a Cloudflare saját DNS-szoftverében egy belső számláló logikailag lehetetlen módon negatív értéket vett fel a szökőmásodperc miatt — ez leállási hibát okozott. A cég szerint ez a DNS-lekérdezések körülbelül 0,2 százalékát, a HTTP-kéréseknek pedig kevesebb mint 1 százalékát érintette, a hibát 90 percen belül kijavították.
A probléma nemcsak internetes szolgáltatásokat érintett. 2008. december 31-én a Microsoft Zune 30 lejátszói egy harmadik féltől származó vezérlő hibás ciklusa miatt tömegesen lefagytak — a kód nem tudott kezelni egy 366 napos szökőévet, és a hiba csak 24 óra elteltével oldódott meg magától.
Hogyan kezelik ezt a nagy hírportálok
A nemzetközi hírügynökségek különböző gyakorlatokat dolgoztak ki az időzóna-zavar csökkentésére. A Reuters például jellemzően a helyi időt 12 órás formátumban adja meg, majd zárójelben a GMT-egyenértéket 24 órás formátumban — így egy cikk időpontja bárhol a világon egyértelműen beazonosítható.
A régi cikkek téves, frissnek tűnő megosztása is visszatérő probléma. A Guardian 2019 áprilisában — azt követően, hogy egyes Facebook-oldalak egy 5 évvel korábbi cikket osztottak meg friss hírként a christchurchi mecsetlövöldözés után — feltűnő, sárga figyelmeztető sávot kezdett elhelyezni a 6 hónapnál régebbi cikkeken és azok közösségimédia-előnézetein. A New York Times 2020 októberétől automatikusan megjelöli az 1 évnél régebbi cikkek social media link-előnézeteit, hogy elkerülje a régi tartalom friss híreként való továbbterjedését.
A nemzetközi szerkesztőségek egy másik jellegzetes gyakorlata a szó szerinti „kövesd a napot” elv: amikor egy régióban éjszaka van, egy másik időzónában dolgozó csapat veszi át a lapzárást, így a hírfolyam megszakítás nélkül frissülhet a nap 24 órájában.
