Timpul pare simplu până când încerci să scrii software care îl gestionează corect. Un eveniment programat la „ora 15" înseamnă lucruri diferite în Tokyo, Londra și New York. Ora de vară mută ceasurile înainte sau înapoi — dar nu peste tot și nu la aceleași date. Un marcaj de timp care pare corect în mediul local se strică în producție pentru că serverul este într-un alt fus orar.
Fusurile orare sunt una dintre cele mai constant confuze subiecte în dezvoltarea software. Acest articol explică cum funcționează, de unde vine complexitatea și cum să eviți cele mai frecvente greșeli.
De ce există fusurile orare
Pământul se rotește cu 360 de grade în 24 de ore, ceea ce înseamnă că soarele este la punctul cel mai înalt în momente diferite în funcție de longitudinea ta. Înainte de secolul al XIX-lea, fiecare oraș își regla ceasurile după ora solară locală — amiaza era când soarele era deasupra capului. Aceasta funcționa bine până când căile ferate au conectat orașe îndepărtate și un orar de tren avea nevoie de un singur ceas consistent.
În 1884, delegați din 25 de națiuni s-au întâlnit la Conferința Internațională a Meridianului în Washington, D.C. și au convenit să împartă lumea în 24 de fusuri orare standard, fiecare decalat de la meridianul de bază (0 grade longitudine) care trece prin Greenwich, Anglia.
În practică, limitele fusurilor orare urmează granițele politice, nu linii longitudinale ordonate. China acoperă cinci zone geografice dar folosește un singur timp oficial (UTC+8). India folosește UTC+5:30 — un decalaj de o jumătate de oră. Nepal folosește UTC+5:45. Harta reală a fusurilor orare este dezordonată.
UTC vs. GMT
GMT (Greenwich Mean Time) este timpul solar mediu la Observatorul Regal din Greenwich. A fost referința temporală a lumii timp de peste un secol.
UTC (Coordinated Universal Time) a înlocuit GMT ca standard internațional în 1972. UTC se bazează pe ceasuri atomice în loc de observații astronomice, făcându-l mult mai precis. Pentru majoritatea scopurilor practice, UTC și GMT arată același timp, dar UTC este referința tehnică corectă.
De ce „UTC" și nu „CUT"? Abrevierea este un compromis între engleza „Coordinated Universal Time" (CUT) și franceza „Temps Universel Coordonné" (TUC). Niciuna dintre părți nu a obținut abrevierea preferată, așa că UTC a fost ales ca alternativă neutră din punct de vedere lingvistic.
Ora de vară: haos organizat
Aproximativ 70 de țări observă ora de vară (DST), mutând ceasurile cu o oră înainte primăvara și înapoi toamna. Intenția este alinierea orelor de veghe cu lumina zilei. Rezultatul este o sursă semestrială de erori.
Complicații cheie:
- Nu este universală. Majoritatea Africii, Asiei și Americii de Sud nu observă DST. În SUA, Arizona și Hawaii renunță.
- Date diferite. UE schimbă în ultima duminică din martie și octombrie. SUA schimbă în a doua duminică din martie și prima duminică din noiembrie. Sunt desincronizate câteva săptămâni pe an.
- Timpi ambigui. Când ceasurile se dau înapoi, ora de la 1:00 la 2:00 dimineața apare de două ori. Un marcaj de timp de „1:30" în acea zi este ambiguu.
- Timpi omisi. Când ceasurile se dau înainte, ora de la 2:00 la 3:00 dimineața nu există. O întâlnire programată la 2:30 dimineața în acea zi nu se întâmplă niciodată.
- Schimbări politice. Guvernele pot (și chiar schimbă) regulile DST cu puțin preaviz. Rusia a adoptat DST permanent în 2011, apoi a trecut la ora standard permanentă în 2014. Maroc a schimbat regulile DST de mai multe ori.
ISO 8601: formatul universal de dată
Pentru a evita ambiguitatea, standardul internațional ISO 8601 definește un format clar de dată și oră:
2026-03-29T14:30:00Z
2026-03-29T14:30:00+02:00
2026-03-29T14:30:00-05:00
Tsepară data de oră.Zînseamnă UTC (fusul orar „Zulu" în terminologia militară).+02:00sau-05:00este decalajul UTC.
Acest format este neambiguu, sortabil ca text simplu și înțeles universal de bibliotecile de analiză a datelor. Când ai dubii, folosește ISO 8601.
Marcaje de timp Unix
Un marcaj de timp Unix (numit și epoch time sau POSIX time) este numărul de secunde scurse de la 1 ianuarie 1970, 00:00:00 UTC — un moment cunoscut ca Unix epoch.
| Lizibil pentru oameni | Marcaj de timp Unix |
|---|---|
| 1970-01-01 00:00:00 UTC | 0 |
| 2000-01-01 00:00:00 UTC | 946684800 |
| 2026-03-29 12:00:00 UTC | 1774987200 |
Marcajele de timp Unix nu au fus orar — sunt întotdeauna în UTC. Aceasta le face ideale pentru stocarea și compararea timpilor în software. Conversia la un fus orar local se face doar la nivelul de afișare.
Problema anului 2038: Sistemele care stochează marcajele de timp Unix ca un întreg cu semn pe 32 de biți vor depăși capacitatea pe 19 ianuarie 2038 la 03:14:07 UTC. Valoarea maximă (2.147.483.647) se transformă într-un număr negativ, interpretat ca decembrie 1901. Majoritatea sistemelor moderne folosesc întregi pe 64 de biți, care nu vor depăși capacitatea încă 292 de miliarde de ani.
Baza de date IANA a fusurilor orare
Software-ul nu are nevoie doar de decalaje UTC — trebuie să cunoască istoricul complet și regulile viitoare pentru fiecare regiune, inclusiv tranzițiile DST, schimbările politice și anomaliile istorice. Aceste informații se află în Baza de date IANA a fusurilor orare (cunoscută și ca baza Olson sau tzdata).
Folosește identificatori ca America/New_York, Europe/Paris, Asia/Tokyo. Fiecare intrare codifică istoricul complet al decalajelor UTC și regulilor DST pentru acea locație.
De aceea nu ar trebui niciodată să stochezi un fus orar ca un decalaj fix precum „+02:00". Un decalaj îți spune diferența curentă față de UTC dar nu spune nimic despre regulile DST. Europe/Paris este UTC+1 iarna și UTC+2 vara. Identificatorul IANA le captează pe amândouă.
Erori comune în software
- Stocarea orei locale fără fus orar. O valoare ca
2026-03-29 14:30:00este lipsită de sens fără a ști la ce fus orar se referă. Stochează întotdeauna UTC sau include decalajul. - Presupunerea că decalajul UTC echivalează cu fusul orar. UTC+2 în martie ar putea fi UTC+3 în iulie (dacă regiunea observă DST). Stochează identificatorul IANA, nu decalajul.
- Ignorarea tranzițiilor DST în planificare. O sarcină zilnică la 2:30 dimineața va fi omisă o dată pe an și va rula de două ori o dată pe an dacă nu gestionezi DST.
- Presupunerea că zilele au 24 de ore. În zilele de tranziție DST, o zi are 23 sau 25 de ore. Calculul „mâine la aceeași oră" prin adăugarea a 86.400 de secunde va fi decalat cu o oră.
- Utilizarea naivă a JavaScript
Date.new Date("2026-03-29")este analizat ca UTC în unele motoare și ca ora locală în altele. Fii întotdeauna explicit cu privire la fusul orar.
Cele mai bune practici pentru dezvoltatori
- Stochează timpii în UTC. Convertește la fusul orar local al utilizatorului doar la nivelul de prezentare.
- Folosește identificatori IANA de fus orar (
America/New_York), nu decalaje fixe (-05:00). - Folosește ISO 8601 pentru serializare. Este neambiguu și universal parsabil.
- Folosește o bibliotecă matură de date. În JavaScript, folosește
Intl.DateTimeFormatsau o bibliotecă cadate-fns-tz. În Python, foloseștezoneinfo(3.9+) saupytz. În Java, foloseștejava.time.ZonedDateTime. - Menține
tzdataactualizată. Guvernele schimbă regulile DST. Sistemul tău de operare și mediul de rulare au nevoie de date actuale ale fusurilor orare. - Testează cu mai multe fusuri orare. Nu presupune că serverul și utilizatorii tăi sunt în același fus.
Mai departe
Timpul este înșelător de complex, dar regulile sunt bine documentate și instrumentele sunt mature. Cheia este respectarea complexității în loc de a o ignora.
- Expresii Cron demistificate — planificarea sarcinilor în diferite fusuri orare
- Generator de hash și Tester Regex — mai multe instrumente pentru dezvoltatori pe ToolK