„05.03.2024" oznacza w Polsce 5 marca — a w Stanach Zjednoczonych ten sam ciąg znaków to 3 maja. Ta jedna różnica konwencji zapisu powoduje w praktyce więcej błędów przy liczeniu różnicy dat niż lata przestępne i strefy czasowe razem wzięte, bo „źle odczytana" data nadal wygląda w pełni poprawnie.
DD.MM.RRRR kontra MM/DD/RRRR
W Polsce, podobnie jak w większości Europy, najpierw zapisuje się dzień: 05.03.2024 to 5 marca. W USA najpierw jest miesiąc — ten sam ciąg znaków oznacza tam 3 maja. Jeśli data z amerykańskiego API albo arkusza zostanie odczytana według polskiej konwencji, obliczona różnica dat może się pomylić o całe tygodnie, bez żadnego błędu w kodzie.
Format bez dwuznaczności: ISO 8601
Zapis 2024-03-05 (rok-miesiąc-dzień) jest odczytywany tak samo w każdym kraju, dlatego jest standardem w API, bazach danych i logach — zresztą coraz częściej używany też w polskich dokumentach urzędowych. Gdy przy wymianie dat między systemami można wybrać format, ISO 8601 usuwa ten problem raz na zawsze.
Strefy czasowe i granice doby
Jeśli daty zawierają godzinę, a nie tylko dzień, różnica stref czasowych może przesunąć wynik liczenia dni o jeden: 23:30 w Warszawie i 17:30 w tym samym momencie w Nowym Jorku mogą przypadać na różne dni kalendarzowe, zależnie od strefy przyjętej do liczenia.
Do czego to się przydaje
- Obliczenie dokładnej liczby dni do terminu lub od daty rozpoczęcia projektu.
- Sprawdzenie, czy umowa najmu, subskrypcja lub gwarancja nadal obowiązuje.
- Wychwycenie daty odczytanej w złym formacie, zanim zepsuje cały raport.
Dlaczego „różnica w miesiącach" nie ma jednej poprawnej odpowiedzi
Odjęcie miesiąca od 31 marca daje niejednoznaczny wynik — 31 lutego nie istnieje, więc jedne systemy zaokrąglają do 28 lutego, inne przenoszą nadmiarowe dni na 3 marca. Oba podejścia są uzasadnione, ale się nie zgadzają — warto o tym pamiętać, gdy wynik nie pasuje do innego narzędzia.