Artykuł

Znaczniki czasu Unix i wyrażenia cron

Znacznik czasu Unix to po prostu liczba całkowita. Wyrażenie cron to po prostu pięć pól. Oba pojawiają się nieustannie w pracy backendowej i oba wprowadzają w błąd w przewidywalny sposób: pierwsze przez strefy czasowe, drugie przez jednostkę.

Napisał Bastien Sulyan · Opublikowano 28 czerwca 2026

Czym jest znacznik czasu Unix

Znacznik czasu Unix zlicza liczbę sekund, które upłynęły od 1970-01-01 00:00:00 UTC, punktu odniesienia zwanego epoką Unix. Ta definicja ma dwie ważne konsekwencje. Po pierwsze, liczenie jest w UTC: w samej liczbie nie jest osadzona żadna strefa czasowa. 1718400000 oznacza tę samą chwilę na całej Ziemi, bez względu na to, gdzie znajduje się przechowująca ją maszyna. Po drugie, epoka jest definiowana w sekundach, a nie w żadnej innej jednostce. Wartość taka jak 1718400000 to zawsze sekundy od północy 1 stycznia 1970 UTC, chyba że system lub protokół wyraźnie dokonał innego wyboru. Znaczniki czasu są z założenia wolne od stref czasowych, co jest właśnie powodem ich przydatności do logowania, baz danych i komunikacji między systemami, gdzie zegary w różnych regionach muszą jednoznacznie odnosić się do tej samej chwili.

Oś czasu pokazująca epokę Unix w 1970-01-01 00:00:00 UTC po lewej, bieżący znacznik czasu w środku i granicę przepełnienia 2038 po prawej, oznaczoną jako maksimum 32-bitowej liczby całkowitej ze znakiem.

Sekundy, milisekundy i problem roku 2038

Wiele nowoczesnych środowisk uruchomieniowych i interfejsów API używa milisekund zamiast sekund. Funkcja Date.now() w JavaScript zwraca milisekundy, więc 1718400000000 to ta sama chwila co wartość z dokładnością do sekund 1718400000. Gdy otrzymujesz nieznajomy znacznik czasu, jego rząd wielkości mówi o jednostce: liczba 10-cyfrowa to prawie zawsze sekundy; liczba 13-cyfrowa to prawie zawsze milisekundy. Problem roku 2038 wynika z innego wyboru: przechowywania znacznika czasu z dokładnością do sekund w 32-bitowej liczbie całkowitej ze znakiem. Maksymalna wartość 32-bitowej liczby całkowitej ze znakiem to 2147483647, co odpowiada 2038-01-19 03:14:07 UTC. Po tej sekundzie licznik przepełnia się do dużej liczby ujemnej, a data cofa się do 1901 na systemach, które nie obsługują tej granicy. Poprawką jest użycie 64-bitowego przechowywania. Większość obecnych systemów operacyjnych i baz danych już to robi, ale systemy wbudowane, urządzenia sieciowe i stare formaty plików, które ustaliły szerokość pola dziesiątki lat temu, pozostają zagrożone.

Konwersja epoch na datę czytelną dla człowieka: etap strefy czasowej

Konwersja wartości epoch na czytelną datę wymaga dwóch kroków: pobrania składników daty UTC z liczby całkowitej, a następnie zastosowania przesunięcia UTC w celu uzyskania czasu lokalnego. Sam znacznik czasu jest w UTC. Gdy pytasz, jaką datę reprezentuje 1718325000, prawidłową odpowiedzią jest 2024-06-14, 00:30 w UTC. W Nowym Jorku (UTC-4 latem) ta sama sekunda przypada na 2024-06-13, 20:30 wieczorem dnia poprzedniego: zmienia się data, nie tylko godzina. To etap, który pomijany daje błędne wyniki: deweloper loguje surowy znacznik czasu w UTC, narzędzie raportujące renderuje go w czasie lokalnym bez konwersji, a data wydaje się być przesunięta o godziny lub pełną dobę. Narzędzie timestamp-converter na Sunasty obsługuje to wprost: wpisujesz wartość epoch, a narzędzie pokazuje datę i godzinę UTC obok własnej lokalnej daty i godziny Twojego urządzenia, dzięki czemu przekroczenie granicy doby, takie jak to, jest widoczne na pierwszy rzut oka. Konwersja działa w całości w przeglądarce i nic, co wklejasz, nie jest nigdzie przesyłane.

Dwie siatki kalendarza obok siebie dla tej samej wartości epoch: siatka UTC podświetla jeden dzień kalendarzowy, a siatka Nowego Jorku (UTC-4) podświetla poprzedni dzień, pokazując, jak data lokalna cofa się w wyniku różnicy stref czasowych.

Składnia cron: pięć pól, zakresy, kroki i listy

Wyrażenie cron planuje cykliczne zadania w systemach uniksopodobnych. Standardowa składnia ma pięć pól oddzielonych spacjami: minuta (0-59), godzina (0-23), dzień-miesiąca (1-31), miesiąc (1-12), dzień-tygodnia (0-7, gdzie zarówno 0, jak i 7 oznaczają niedzielę). Gwiazdka (*) w polu oznacza "każda prawidłowa wartość". Wyrażenie 30 8 * * 1-5 uruchamia się o 08:30 od poniedziałku do piątku. Zakresy używają łącznika: 1-5 obejmuje wartości 1, 2, 3, 4, 5. Listy używają przecinków: 1,15 oznacza 1. i 15. Kroki używają ukośnika: */15 w polu minut oznacza co 15 minut (0, 15, 30, 45). Te kombinatory mogą się ze sobą łączyć: 0-30/10 oznacza 0, 10, 20, 30. Jedną rzeczą, której cron nie ma, jest pole strefy czasowej. Demon odczytuje zegar maszyny, na której działa, ustawiony na lokalną strefę czasową serwera. Jeśli serwer działa na UTC, a deweloper oczekuje czasu lokalnego, harmonogram uruchamia się o złej godzinie zegarowej. Praktyczna zasada: traktuj harmonogramy cron jako wyrażenia w czasie lokalnym serwera i dokumentuj strefę czasową serwera obok linii cron.

Lokalne użycie timestamp-converter

Narzędzie timestamp-converter na Sunasty konwertuje w obu kierunkach: epoch na datę czytelną dla człowieka i datę z powrotem na epoch. Możesz wprowadzić wartość z dokładnością do sekund lub milisekund; narzędzie wykrywa jednostkę na podstawie rzędu wielkości. Pokazuje wynik jednocześnie w UTC i we własnej lokalnej strefie czasowej Twojego urządzenia, wraz z surowymi wartościami w sekundach i milisekundach gotowymi do skopiowania. Przycisk Teraz wypełnia bieżący znacznik czasu jednym kliknięciem, co jest szybkim sposobem na sprawdzenie bieżącego czasu Unix bez otwierania terminala. Nie ma osobnego selektora strefy czasowej: kolumna lokalna zawsze odzwierciedla strefę czasową aktualnie ustawioną w Twojej przeglądarce. Wszystko to działa w przeglądarce. Wartość wklejona w pole jest odczytywana przez JavaScript po stronie klienta i nigdy nie opuszcza urządzenia.

Narzędzia w tym artykule

Najczęściej zadawane pytania

Dlaczego JavaScript używa milisekund zamiast sekund?

Obiekt Date w JavaScript został zaprojektowany od początku z obsługą precyzji poniżej sekundy, a milisekundy dają tysiąckrotnie większą rozdzielczość niż sekundy bez potrzeby stosowania przecinka. Kompromisem są większe wartości, dlatego Date.now() zwraca liczbę 13-cyfrową, podczas gdy większość serwerowych znaczników czasu to 10 cyfr.

Czy każdy serwer uruchamiający cron musi być na UTC?

Nie, ale uruchamianie serwerów na UTC to powszechna praktyka właśnie dlatego, że usuwa niejednoznaczność. Gdy serwer jest na UTC, wyrażenie cron takie jak 0 2 * * * oznacza 02:00 UTC i ten czas jest stabilny przez cały rok. Na serwerze w strefie stosującej czas letni to samo zadanie uruchamia się o innej chwili UTC latem i zimą, a przy zmianie zegara może uruchomić się dwa razy lub raz pominąć.

Jaki jest bezpieczny typ przechowywania dla znaczników czasu po 2038 roku?

64-bitowa liczba całkowita ze znakiem przechowuje znaczniki czasu z dokładnością do sekund do roku 292277026596, co jest daleko poza jakimkolwiek praktycznym zmartwieniem. Większość obecnych baz danych domyślnie przechowuje znaczniki czasu jako wartości 64-bitowe. Jeśli pracujesz ze starszym schematem lub binarnym formatem pliku używającym pól 32-bit, migracja do przechowywania 64-bitowego przed granicą 2038 to właściwa poprawka.