A nyári időszámítás: szoftverhiba-forrás és megoldatlan uniós vita
Az óraátállítás — a nyári és a téli időszámítás közötti évi kétszeri váltás — külön hibaforrás a szoftverek számára. Amikor az órát visszaállítják, egy adott óra kétszer következik be, ami duplikált időbélyegeket eredményezhet; amikor előreállítják, egy óra „nem is létezik”, amit a rosszul megírt rendszerek hibásan kezelhetnek. Ilyen hibát jelentett például egy felhasználó egy népszerű adatbázis-alapú alkalmazás fórumán is: óraátállítás után duplikált, illetve hiányzó időbélyegű bejegyzések jelentek meg a rendszerében.
A tagállamok azonban a Tanács szintjén nem tudtak megegyezni abban, hogy melyik időt — a téli vagy a nyári számítást — tegyék véglegessé, és a folyamat 2019 óta lényegében leállt. 2025-ben a lengyel EU-elnökség próbálta újraindítani az ügyet, az Európai Bizottság pedig újabb hatásvizsgálatot jelentett be; ugyanakkor a Bizottság a bürokrácia-egyszerűsítést célzó „Omnibus” csomag részeként azt is fontolgatja, hogy teljesen levegye a napirendről a javaslatot. Spanyolország 2025 októberében külön indítványozta a megszüntetést 2026-tól. 2026 szeptemberéig azonban nem született végleges döntés — az óraátállítás továbbra is érvényben van.
Fejlesztői buktatók: a névadástól az időzónákig
A szoftverfejlesztés egyik legismertebb mondása Phil Karltontól, a Netscape egykori fejlesztőjétől származik: „A számítástudományban csak két nehéz dolog van: a gyorsítótár érvénytelenítése és a dolgok elnevezése.” A szakmai közösség szívesen bővíti ezt tovább — a legelterjedtebb variáns Jeff Atwoodtól, a Stack Overflow egyik alapítójától származik, aki hozzáteszi az „off-by-one hibákat” (amikor egy számlálás eggyel el van csúszva) — a vicc éppen az, hogy „két dolog” helyett hármat sorol fel. Az időzónák kezelése gyakran szerepel negyedik vagy ötödik tagként ezekben a bővített listákban, és ez nem véletlen: tipikus hiba, ha egy rendszer a helyi időt időzóna-információ nélkül tárolja (később nem állítható vissza, melyik pontos UTC-pillanatra utalt), ha a „nap eleje/vége” számítást szerveridő szerint végzik a felhasználó saját időzónája helyett, vagy ha a fejlesztői/teszt-környezet UTC-ben fut, és egy más időzónás hiba csak élesben derül ki.
Hosszabb távon egy még nagyobb, rendszerszintű időkezelési probléma is ismert: a 2038-as probléma. Sok rendszer a Unix-időt (az 1970. január 1., UTC óta eltelt másodperceket) egy előjeles, 32 bites egész számban tárolja — ez 2038. január 19-én, 03:14:07 UTC-kor túlcsordul, és az érintett, nem javított rendszerek 1901-re „esnek vissza”. A hiba jó illusztrációja annak, hogy a mérnöki döntések évtizedekkel később is problémát okozhatnak.
Amikor a Föld szélén ér véget — vagy kezdődik — a nap
A földrajz néha még a szabványoknál is szélsőségesebb helyzeteket teremt. A csendes-óceáni Kiribati államban a Line-szigetek (köztük Kiritimati, azaz Karácsony-sziget) a Föld „legkorábbi” időzónájában, UTC+14:00-ban vannak. Ez nem véletlen: 1994. december 31-én Kiribati saját keleti felét UTC−11:00/−10:00-ról UTC+13:00/+14:00-ra helyezte át, hogy az egész ország a nemzetközi dátumvonal ugyanazon oldalára kerüljön — korábban a hivatalok a hétnek csak négy napján tudtak egyszerre dolgozni. A döntés jelképes hozadéka volt, hogy Kiritimati üdvözölhette elsőként a 2000-es évet a Földön.
Még szemléletesebb Szamoa esete. 2011. december 29-e után Szamoa átugrotta december 30-át — csütörtök után egyenesen szombat következett —, amikor az ország UTC−11-ről UTC+13-ra váltott, hogy közelebb kerüljön fő kereskedelmi partnereinek (Új-Zéland, Ausztrália, Kína) időzónájához. A kevesebb mint 100 kilométerre fekvő Amerikai Szamoa azonban nem váltott — így a két, egymáshoz földrajzilag nagyon közeli sziget között ma 25 órás időeltérés van.
Ezek a példák — a szökőmásodperc-bugoktól az uniós óraátállítási huzavonáig, a névadási vicctől a csendes-óceáni dátumvonal-ugrásig — mind ugyanazt mutatják: az idő mérése és megjelenítése, ami az emberi tapasztalatban egyszerű és egyértelmű kérdésnek tűnik, a technikai rendszerek szintjén állandó, gondos egyeztetést igénylő feladat. Amíg a szerver, a szerkesztőség és az olvasó három különböző időzónában élhet, a „mikor van ma” kérdésre adott válasz mindig egy kicsit összetettebb, mint amilyennek elsőre látszik.
