Praca z datami w programowaniu to temat, który potrafi sprawić wiele problemów. Strefy czasowe, lata przestępne, różne formaty dat czy nawet przestępna sekunda mogą sprawić, że to, co wydaje się proste, staje się pułapką dla programistów i użytkowników.
Kalendarze w aplikacjach – więcej pułapek, niż się wydaje!
Praca z datami w programowaniu to temat, który potrafi sprawić wiele problemów. Strefy czasowe, lata przestępne, różne formaty dat czy nawet przestępna sekunda mogą sprawić, że to, co wydaje się proste, staje się pułapką dla programistów i użytkowników.
- Dlaczego ten sam timestamp może oznaczać różną godzinę w zależności od lokalizacji?
- Jak UI powinno obsługiwać wybór daty, by nie frustrować użytkownika?
- Czy można uniknąć problemów ze strefami czasowymi?
W tym artykule przyjrzymy się typowym problemom związanym z kalendarzami i datami oraz sposobom ich rozwiązania.
Format daty – różne standardy w różnych krajach
Problem:
DD/MM/YYYYczyMM/DD/YYYY? W Europie standardem jest dzień/miesiąc/rok, ale w USA powszechnie stosuje się miesiąc/dzień/rok.YYYY-MM-DD– format ISO 8601 (zalecany do przechowywania i przesyłania dat w systemach IT).
Rozwiązanie:
W aplikacjach stosuj format ISO 8601 – jest jednoznaczny i unikniesz błędów interpretacyjnych.
Jeśli musisz wyświetlać daty w różnych regionach, pozwól użytkownikowi wybrać format.
Źródło:
W3C: Date and Time Formats (https://www.w3.org/TR/NOTE-datetime)
Strefy czasowe – jeden czas, różne godziny
Problem:
Strefy czasowe mogą wpływać na czas wyświetlany użytkownikowi. Jeśli serwer przechowuje czas w UTC, to użytkownik w Nowym Jorku i Tokio zobaczy różne godziny.
Rozwiązanie:
- Przechowuj czas w UTC i konwertuj go do lokalnej strefy użytkownika.
- Unikaj manualnych obliczeń – używaj bibliotek takich jak day.js czy date-fns.
- Bardzo popularna biblioteka moment.js w tym momencie uznawana jest za przestarzałą, ale day.js zachowuje możliwie pełną kompatybilność składni, więc warto stosować już tę nowszą.
Ciekawostka:
Niektóre kraje zmieniają swoją strefę czasową – Kiribati przesunęło się o 24 godziny do przodu w 1995 roku!
Wikipedia – Time in Kiribati (https://en.wikipedia.org/wiki/Time_in_Kiribati)
Lata przestępne i przestępna sekunda – kiedy kalendarz płata figle
Problem:
- Rok ma zwykle 365 dni, ale co cztery lata dodajemy 29 lutego.
- Czasem dodaje się też przestępną sekundę – ostatnio w 2016 roku.
Rozwiązanie:
Zawsze sprawdzaj, czy dany rok ma 29 lutego.
Przestępną sekundę najlepiej ignorować – większość systemów i tak synchronizuje się z serwerami czasu.
Źródło:
Wikipedia – Przestępny rok (https://pl.wikipedia.org/wiki/Przest%C4%99pny_rok)
UI dla wyboru daty – jak nie frustrować użytkownika?
Zakresy dat – nie pozwól użytkownikowi wybrać daty końcowej wcześniejszej niż początkowa.
Maski wprowadzania – najlepiej umożliwić wybór daty z kalendarza, ale nie wyłączać opcji ręcznego wpisu.
Predefiniowane zakresy – popularne opcje, np. „ostatnie 7 dni”, „bieżący miesiąc” pomagają użytkownikowi szybciej znaleźć odpowiednią datę.
Wskazówka:
Zadbaj o wygodę – uporczywe klikanie w date-picker, bez możliwości ręcznego wpisania daty, to częsty powód frustracji użytkownika.
Timestampy czy standardowe daty?
Timestamp jest jednoznacznym “punktem” na osi czasu.
Problem:
Timestamp (np. 1700000000) to liczba sekund od 1 stycznia 1970 (Unix Epoch).
Daty w formacie tekstowym (np. "2025-03-12") są czytelniejsze, ale wymagają konwersji.
Rozwiązanie:
Do przechowywania i obliczeń używaj timestampów – są uniwersalne i pozwalają uniknąć błędów konwersji.
W interfejsie wyświetlaj daty w formacie czytelnym dla użytkownika.
Dodatkowo:
Stosuj tzw. formaty "human-readable" – np. „2 dni temu” czy „za 3 godziny”. Użytkownicy lepiej przyswajają takie informacje niż dokładne daty i godziny. Przydatne funkcje oferują biblioteki date-fns i luxon.
Kiedy zaczyna się nowy dzień? To zależy!
Problem:
Dzień zwykle zaczyna się o 00:00, ale w niektórych branżach (np. w transporcie lotniczym) nowy dzień może być liczony od innej godziny.
Rozwiązanie:
Dostosuj logikę aplikacji do specyfiki branży. W systemach hotelowych doba zaczyna się o 14:00, a nie o północy.
W niektórych krajach, np. w Japonii, w rozkładach jazdy stosuje się godziny przekraczające 24:00 – np. "28:00", co oznacza 4:00 nad ranem następnego dnia.
Źródło:
Wikipedia – Date and time notation in Japan (https://en.wikipedia.org/wiki/Date_and_time_notation_in_Japan)Który dzień jest pierwszy w tygodniu?
Problem:
W USA i Kanadzie tydzień zaczyna się w niedzielę.
W Europie i większości krajów – w poniedziałek.
Rozwiązanie:
Nie zakładaj domyślnie, że tydzień zaczyna się w poniedziałek – pozwól użytkownikowi wybrać ustawienia.
Obsługa dat na różnych platformach – PHP, JS i HTML
PHP – pozwala mierzyć czas z dokładnością do mikrosekund.
JS – zwraca liczbę milisekund od 1970 roku.
HTML5 – ale uwaga, na iOS nie działa jednolicie!
Rozwiązanie:
Używaj bibliotek takich jak Moment.js, date-fns, Luxon do obsługi dat w JavaScript.
W PHP polegaj na DateTime i Carbon.
Podsumowanie
Zaprojektuj obsługę czasu w zależności od wymagań aplikacji – bez nadmiernego komplikowania.
Jeśli aplikacja nie ma charakteru międzynarodowego – pewne uproszczenia są możliwe. Warto jednak już na wczesnym etapie przemyśleć potencjalny rozwój i skalowanie systemu.
Największe pułapki w obsłudze kalendarzy:
Różne formaty dat – zawsze stosuj ISO 8601.
Strefy czasowe – przechowuj czas w UTC.
Lata przestępne i przestępne sekundy – miej je na uwadze.
UI kalendarzy – umożliwiaj łatwy wybór zakresów i ręczne wpisanie daty.
Ustalanie początku dnia i tygodnia – uwzględniaj kontekst kulturowy i branżowy.