Format wyświetlania nie powinien być formatem przechowywania
Zapis „03/04/2026” wygląda zwyczajnie, ale różni odbiorcy mogą odczytać go jako inne dni. Podobny problem dotyczy kwoty „1,250”: separator może sugerować część dziesiętną albo grupę tysięcy. Jeżeli aplikacja przechowuje takie teksty jako jedyne źródło danych, późniejsze obliczenia i eksport stają się niejednoznaczne. Najpierw określ typ wartości, jednostkę i regułę, a dopiero później sposób prezentacji odpowiedni dla odbiorcy.
W przykładowym programie serwisowym odróżnij datę przeglądu od chwili wysłania zgłoszenia. Pierwsza może być po prostu dniem kalendarzowym bez godziny. Druga jest zdarzeniem w czasie. Nie dodawaj sztucznej północy do każdej daty tylko dlatego, że jeden format bazy wydaje się wygodniejszy. Taka decyzja może po przeliczeniu strefy przesunąć wyświetlany dzień, mimo że nikt nie zmienił terminu przeglądu.
Chwila zdarzenia i lokalny termin to dwa różne modele
Dla zdarzenia potrzebujesz jednoznacznego punktu na osi czasu. Dla planowanego spotkania często potrzebujesz również informacji, w której strefie ma obowiązywać godzina. Nazwa strefy, taka jak Europe/Warsaw, opisuje reguły, których sam stały offset nie zastępuje. Użytkownik nie musi znać technicznych oznaczeń, ale powinien widzieć, do jakiej lokalizacji odnosi się termin, zwłaszcza gdy zaprasza osobę pracującą w innym kraju.
Nie utożsamiaj „jutro o dziewiątej” z dodaniem określonej liczby sekund do bieżącego momentu. W cyklicznych zadaniach istotna może być godzina lokalna, nie stały odstęp. Przy zmianach czasu występują lokalne godziny nieistniejące lub niejednoznaczne. Aplikacja powinna mieć ustaloną regułę obsługi takich przypadków. Ciche przesunięcie terminu bez informacji dla użytkownika jest szczególnie problematyczne, gdy od zadania zależy praca zespołu.
Kwota zawsze potrzebuje waluty i reguły zaokrąglania
Liczba 199 nie opisuje jeszcze ceny. Potrzebujesz waluty, znaczenia kwoty oraz zasad obliczeń. W systemach finansowych stosuje się odpowiednie typy dziesiętne albo liczby całkowite reprezentujące ustaloną jednostkę pomocniczą. Nie zakładaj przy tym, że każda waluta i każdy rodzaj wartości używa identycznej liczby miejsc. Wybór modelu powinien wynikać z zakresu aplikacji, a nie wyłącznie z domyślnego typu liczby w JavaScript.
Na prostym przykładzie podziel koszt zestawu między trzy pozycje i sprawdź, czy suma zaokrąglonych elementów zgadza się z całością. Ustal, gdzie trafia różnica wynikająca z zaokrąglenia. To decyzja biznesowa, której nie powinny niezależnie podejmować frontend, PDF i eksport. Tekst z symbolem waluty jest wynikiem formatowania, nie wartością do dalszego dodawania. Nie parsuj z powrotem widocznego „zł”, jeśli oryginalna liczba jest już dostępna w modelu.
Wprowadzanie danych wymaga jasnych oczekiwań
Pole powinno pokazywać format, który użytkownik rozumie, i komunikować, jak interpretowana jest wartość. Jeżeli dopuszczasz przecinek jako separator dziesiętny, zrób to konsekwentnie i waliduj po stronie serwera. Nie usuwaj automatycznie wszystkich znaków innych niż cyfry: „12,50” mogłoby wtedy zmienić się w „1250”. W przypadku dat unikaj zgadywania między kilkoma formatami, które mogą prowadzić do poprawnych, lecz różnych wyników.
W formularzu terminu pokaż potwierdzenie z nazwą miesiąca i strefą, jeśli ma znaczenie. Osoba wpisująca dane powinna wychwycić pomyłkę przed zapisaniem zadania. Puste pole nie zawsze oznacza zero lub dzisiejszą datę. Rozróżnij brak informacji, wartość domyślną oraz świadome wskazanie użytkownika. Te stany są szczególnie istotne w imporcie, gdzie tysiące wierszy mogą zostać przetworzone bez obejrzenia każdego z osobna.
Używaj narzędzi lokalizacyjnych, ale testuj ich wynik
Rodzina Intl w JavaScript udostępnia narzędzia do formatowania liczb i dat dla wybranych ustawień regionalnych. Pozwala uniknąć ręcznego sklejania separatorów oraz nazw miesięcy. Podaj jednak jawnie potrzebne opcje zamiast opierać ważny dokument na przypadkowym ustawieniu urządzenia. Dwa komputery mogą mieć inny język lub strefę. Wspólny raport powinien mieć zrozumiałą konwencję i informację o niej, niezależnie od komputera osoby pobierającej.
Sprawdź zgodność podglądu w aplikacji, wiadomości i pliku eksportu. W przykładzie obsługi zamówień ta sama kwota ma być rozpoznawalna w panelu klienta oraz wewnętrznym zestawieniu, choć sposób prezentacji może się różnić. Ustal też sortowanie: tekstowe daty w lokalnym formacie nie powinny decydować o kolejności chronologicznej. Sortuj po wartości, a nie po tym, jak wygodnie ją odczytać na ekranie.
Zbuduj zestaw przypadków granicznych
Do testów dodaj koniec miesiąca, rok przestępny, przejście między strefami i zmianę czasu. Sprawdź kwoty zerowe, ujemne, duże oraz takie, które wymagają uzgodnionego zaokrąglenia. Przetestuj użytkownika z polskim interfejsem i inną strefą systemową. Nie ograniczaj prób do bieżącego dnia, bo wiele błędów ujawnia się tylko kilka razy w roku. Zestaw powinien działać niezależnie od daty uruchomienia testu.
Opisz znaczenie pól w kontrakcie danych: dzień kalendarzowy, chwila, lokalny termin, liczba albo kwota z walutą. Taki opis jest potrzebny także osobie integrującej kolejny system. Gdy format i znaczenie są rozdzielone, można zmienić wygląd bez zmieniania wartości. To właśnie jest cel: użytkownik widzi dane naturalnie, a program zachowuje jednoznaczny zapis, który nadaje się do porównania, przeliczenia i bezpiecznego przekazania dalej.