Konwerter Unix timestamp

Liczba wskazuje chwilę, a nie lokalny zapis w kalendarzu

Unix timestamp mierzy czas od początku epoki: 1 stycznia 1970 roku o 00:00:00 UTC. Wartość 0 wskazuje właśnie ten moment, dodatnie liczby opisują chwile późniejsze, a systemy obsługujące liczby ujemne mogą nimi oznaczać daty wcześniejsze. Sam zapis liczbowy nie zawiera polskiej nazwy miesiąca, formatu dnia ani informacji o mieście użytkownika.

Ta sama chwila może zostać pokazana jako 12:00 w Warszawie, 10:00 w UTC i 05:00 przy UTC−5. Nie są to trzy zdarzenia. Różnią się tylko sposobem wyświetlenia jednego punktu na osi czasu. Dzięki temu timestamp dobrze nadaje się do sortowania zdarzeń pochodzących z wielu serwerów i urządzeń.

W drugą stronę nie wystarczy wpisać „11 lipca o 12:00”. Aby wskazać jednoznaczną chwilę, potrzebny jest jeszcze offset albo reguły konkretnej strefy. Bez tego zapis kalendarzowy jest lokalną informacją, którą dwa systemy mogą zinterpretować inaczej.

UTC porządkuje dane, lecz użytkownik zwykle chce zobaczyć czas lokalny

W logu lub bazie warto przechowywać moment w UTC, ponieważ nie przeskakuje on przy zmianie czasu letniego. Interfejs może następnie przeliczyć tę chwilę na strefę odbiorcy. To rozdziela zapis techniczny od prezentacji, na przykład „2026-07-11 10:00 UTC” od „11.07.2026, 12:00 czasu lokalnego”.

Offset UTC+2 mówi jedynie, że zegar jest przesunięty o dwie godziny do przodu względem UTC w rozpatrywanym momencie. Nie mówi, dlaczego obowiązuje takie przesunięcie ani kiedy ma się zmienić. To ważna różnica między prostym offsetem a nazwą strefy taką jak Europe/Warsaw.

Konwerter stosuje wybrany stały offset. Jest to wygodne przy odczytywaniu rekordu, którego offset już znamy, oraz w prostych testach integracji. Nie jest to kalendarz historycznych i przyszłych zmian prawa dotyczących czasu urzędowego.

Różnica jednostki zmienia wartość tysiąckrotnie

Część interfejsów zwraca liczbę sekund od epoki, a JavaScript i wiele narzędzi frontendowych posługuje się milisekundami. Dla tej samej chwili wartości mogą wyglądać jak 1783764000 oraz 1783764000000. Dopisanie lub usunięcie trzech zer nie jest zmianą daty, lecz jednostki.

Gdy liczba sekundowa zostanie potraktowana jak milisekundy, wynik często ląduje w styczniu 1970 roku. Gdy milisekundy trafią do pola oczekującego sekund, data może wyjść daleko poza sensowny zakres. Taki wynik zwykle nie oznacza uszkodzonego zegara serwera — najpierw trzeba sprawdzić kontrakt danych.

Wybór jednostki w formularzu dotyczy zarówno odczytu timestampu, jak i formatu liczby zwracanej przy konwersji daty. Wyniki pomocnicze pokazują obie reprezentacje, dzięki czemu można porównać je z payloadem API bez liczenia zer ręcznie.

Liczba cyfr jest wskazówką, ale nie stanowi bezpiecznej walidacji

Dla współczesnych dat zapis sekundowy zwykle ma dziesięć cyfr, a milisekundowy trzynaście. Ta reguła pomaga szybko zauważyć pomyłkę podczas debugowania, lecz zależy od epoki i zakresu dat. Nie powinna zastępować jawnego pola jednostki w dokumentacji API lub schemacie bazy.

Wartość może przyjść również jako tekst, liczba zmiennoprzecinkowa albo mikrosekundy. Zaokrąglenie ułamka sekund usuwa precyzję, a bardzo duże liczby mogą przekroczyć dokładność bezpiecznego typu liczbowego. Jeżeli kolejność zdarzeń na poziomie mikrosekund ma znaczenie, format danych trzeba ustalić osobno.

Najczytelniejsze nazwy pól ujawniają jednostkę: created_at_seconds, expires_at_ms albo osobny opis w specyfikacji. Pole nazwane tylko time lub timestamp wymusza zgadywanie i przenosi ryzyko na każdy system, który później odczyta rekord.

Kalendarz przyjmuje polski zapis dnia niezależnie od ustawień przeglądarki

Datę można wybrać z kalendarza albo wpisać w formacie dd.mm.rrrr. Osobne pola godziny, minut i sekund zapobiegają niejasnościom takim jak am/pm. Wybrany offset również jest jawny, więc obliczenie nie korzysta po cichu ze strefy systemu operacyjnego.

To szczególnie przydatne przy analizie zgłoszenia od osoby w innej strefie. Można odtworzyć podany przez nią czas i offset, a potem porównać uzyskany timestamp z logiem serwera. Zmiana własnej strefy w systemie nie powinna być częścią takiego testu.

Formularz waliduje dzień i zakresy godziny. Nadal warto sprawdzić, czy źródłowy zapis nie był już w UTC. Ponowne odjęcie offsetu przesuwa prawidłowy moment po raz drugi i daje wynik formalnie poprawny, lecz merytorycznie błędny.

Te same cyfry mogą oznaczać sekundy albo milisekundy

Wartość Unix timestamp nie zawiera separatorów ani nazwy strefy, dlatego pierwszą kontrolą powinna być jej skala. Dziesięciocyfrowe liczby spotykane współcześnie zazwyczaj oznaczają sekundy. Trzynastocyfrowe wartości często są milisekundami używanymi przez JavaScript. Pomylenie tych formatów nie daje niewielkiego przesunięcia: może przenieść datę o tysiące lat albo spowodować przepełnienie w systemie, który oczekuje mniejszego zakresu.

Nie warto rozpoznawać jednostki wyłącznie na podstawie długości ciągu, gdy dane mogą dotyczyć odległej przeszłości, przyszłości albo zawierać ułamki sekundy. Najlepszym źródłem jest kontrakt API, definicja kolumny lub dokumentacja zdarzenia. W interfejsie konwertera wybór sekund i milisekund jest jawny, dzięki czemu można sprawdzić obie interpretacje bez niekontrolowanego zaokrąglenia.

UTC przechowuje chwilę, a strefa tworzy lokalny zapis

Timestamp opisuje moment na osi czasu, więc nie zmienia się po wyświetleniu w Warszawie, Londynie czy Nowym Jorku. Zmieniają się natomiast data kalendarzowa i godzina pokazane użytkownikowi. Jeżeli 23:30 UTC zostanie przedstawione w strefie UTC+2, lokalnie będzie już 01:30 następnego dnia. Właśnie dlatego logi techniczne najlepiej przechowywać w UTC, a strefę stosować dopiero przy prezentacji lub raporcie.

Stały offset, taki jak UTC+1, nie jest pełną strefą czasową. Europe/Warsaw zawiera reguły historyczne i zmiany czasu letniego, podczas gdy liczba +1 opisuje tylko jedno przesunięcie. Formularz z offsetem służy do kontrolowanej konwersji konkretnej chwili; przy harmonogramach cyklicznych i datach historycznych potrzebna jest biblioteka stref czasowych oraz identyfikator regionu.

• Do logów zapisuj timestamp oraz, jeśli to potrzebne, oryginalną strefę zdarzenia.
• W API jednoznacznie nazwij pole i jednostkę, na przykład createdAtMs.
• W eksporcie dla człowieka dodaj offset lub skrót strefy obok godziny.
• Nie obliczaj zmian czasu letniego przez ręczne dodawanie jednej godziny.

Granice typu danych i problem roku 2038

Starsze systemy zapisujące sekundy w 32-bitowej liczbie całkowitej ze znakiem osiągną granicę 19 stycznia 2038 roku. Nowoczesna aplikacja może obliczyć późniejszy timestamp poprawnie, lecz integracja z urządzeniem, biblioteką lub bazą o takim ograniczeniu nadal może się nie udać. Przed przesłaniem dat rezerwacji, certyfikatów czy długich harmonogramów warto sprawdzić typ kolumny oraz zakres po stronie odbiorcy.

Drugi problem dotyczy precyzji liczb zmiennoprzecinkowych i bardzo dużych wartości w milisekundach lub mikrosekundach. Jeżeli system wymaga dokładnego identyfikowania kolejności zdarzeń, sama liczba JavaScript może nie wystarczyć; bezpieczniejszy bywa typ całkowity o odpowiedniej szerokości albo tekst zgodny ze specyfikacją. Konwerter pomaga zweryfikować znaczenie liczby, lecz nie zastępuje kontroli schematu danych i reguł serializacji.