Skip to content

Konwerter Unix timestamp i epoch — wielokrotna precyzja

Błyskawicznie konwertuj Unix timestamp na datę. Automatyczne wykrywanie sekund, milisekund i mikrosekund. Zegar na żywo, dwukierunkowo. Bezpłatnie i prywatnie.

Bez śledzenia Działa w przeglądarce Bezpłatne
Całe przetwarzanie odbywa się w przeglądarce. Żadne dane nie są wysyłane na serwer.

Aktualny Unix timestamp

0

Szybka ściągawka

Przykłady kodu

Sprawdzono pod kątem zgodności z POSIX i dokładności precyzji — Zespół inżynierski Go Tools · Mar 22, 2026

Czym jest Unix timestamp (czas epoch)?

Unix timestamp (zwany też czasem epoch lub czasem POSIX) to liczba sekund, które upłynęły od 1 stycznia 1970 00:00:00 UTC, stanowiąca uniwersalne odniesienie czasu dla praktycznie wszystkich systemów komputerowych. Od jąder Linuksa i baz SQL po silniki JavaScript i mobilne systemy operacyjne — niemal każda nowoczesna platforma przechowuje i wymienia czas właśnie w postaci Unix timestamp.

Jak formalnie definiuje to standard IEEE Std 1003.1 (POSIX): „Unix epoch (1 stycznia 1970 00:00:00 UTC) służy jako punkt zerowy czasu POSIX” — konwencja przyjęta tak powszechnie, że stała się de facto światowym standardem dla maszynowo czytelnych timestamp. Z Unix timestamp korzysta zdecydowana większość systemów serwerowych, baz danych i protokołów sieciowych, w tym header HTTP, JWT token oraz praktycznie każde REST API.

Sama Unix epoch — 1 stycznia 1970 — nie została wybrana przypadkowo. Unix powstał w Bell Labs pod koniec lat 60., a rok 1970 był wygodnym, okrągłym punktem startu — wystarczająco bliskim teraźniejszości, aby wszystkie istotne daty mieściły się w rozsądnych liczbach całkowitych. Każdy moment w czasie można wyrazić jako 64-bitową liczbę całkowitą ze znakiem oznaczającą liczbę sekund od tego punktu odniesienia. Daty sprzed epoch zapisuje się liczbami ujemnymi: 31 grudnia 1969 o północy UTC to -86400 (czyli jeden dzień, 86 400 sekund, przed epoch).

Współczesne systemy często wymagają precyzji większej niż całe sekundy. W tym celu timestamp wyraża się zwykle w milisekundach (tysięcznych częściach sekundy, jak zwraca `Date.now()` w JavaScript czy `System.currentTimeMillis()` w Javie) albo w mikrosekundach (milionowych częściach sekundy, używanych w bazach takich jak PostgreSQL oraz w systemach handlu wysokich częstotliwości). Precyzję rozpoznaje się po liczbie cyfr: 10 cyfr oznacza sekundy, 13 cyfr — milisekundy, a 16 cyfr — mikrosekundy. Ten konwerter automatycznie wykrywa precyzję wartości wejściowej.

Unix timestamp jest fundamentem systemów rozproszonych, ponieważ jest niezależny od strefy czasowej, monotonicznie rosnący (w normalnych warunkach) i trywialnie sortowalny jako liczba całkowita. Przechowywanie czasu jako timestamp i konwersja na format czytelny dla człowieka dopiero w warstwie wyświetlania to dobra praktyka, która eliminuje całe kategorie błędów związanych ze strefami czasowymi. Kompromisem jest czytelność — surowa wartość taka jak 1741965432 jest nieprzejrzysta bez konwertera, i właśnie tę funkcję pełni to narzędzie.

Wszystkie konwersje wykonywane są wyłącznie w przeglądarce z użyciem JavaScript Date API — żadne timestamp, daty ani inne dane nie są wysyłane na serwer. To narzędzie błyskawicznie konwertuje dowolny Unix timestamp — w tym aktualny czas epoch widoczny w zegarze powyżej — na czytelną dla człowieka datę, z pełnym zachowaniem prywatności.

Timestamp jest blisko związany z innymi narzędziami programistycznymi. UUID v1 i v7 osadzają timestamp bezpośrednio w identyfikatorach, a odpowiedzi API zawierające timestamp najwygodniej przeglądać w narzędziu do formatowania JSON. Pogłębione omówienie precyzji, obsługi stref czasowych i pułapek związanych z czasem letnim, wraz z przykładami kodu w JavaScript, Pythonie i Go, znajduje się w naszym przewodniku po Unix timestamp.

// Get the current Unix timestamp in JavaScript
const timestampSeconds = Math.floor(Date.now() / 1000);
console.log(timestampSeconds); // → 1741965432

// Milliseconds (native JavaScript)
const timestampMs = Date.now();
console.log(timestampMs); // → 1741965432000

// Convert timestamp back to a Date object
const date = new Date(timestampSeconds * 1000);
console.log(date.toISOString()); // → '2025-03-14T15:37:12.000Z'

// Python equivalent
// import time
// timestamp = int(time.time())  # → 1741965432

Najważniejsze funkcje

Automatyczne wykrywanie precyzji

Narzędzie samo rozpoznaje, czy timestamp jest w sekundach (10 cyfr), milisekundach (13 cyfr) czy mikrosekundach (16 cyfr) — bez ręcznego przełączania trybów.

Konwersja dwukierunkowa

Można konwertować timestamp na czytelne daty albo wybrać dowolną datę i godzinę, aby od razu otrzymać odpowiadający Unix timestamp we wszystkich trzech precyzjach.

Zegar epoch na żywo

Aktualny Unix timestamp tyka w czasie rzeczywistym, dzięki czemu zawsze masz pod ręką dokładny punkt odniesienia do konwersji i obliczeń.

Wieloformatowe wyniki

Każda konwersja zwraca jednocześnie czas UTC, lokalną strefę czasową, format ISO 8601 oraz przyjazny człowiekowi czas relatywny (np. „3 dni temu”).

100% przetwarzania w przeglądarce

Wszystkie konwersje wykonywane są wyłącznie w przeglądarce z użyciem JavaScript Date API. Żadne timestamp, daty ani dane osobowe nie są przesyłane na serwer.

Unix timestamp a inne formaty daty

ISO 8601

2025-03-14T15:37:12Z

Jednocześnie czytelny dla człowieka i sortowalny leksykograficznie. Standard wymiany danych i API. Preferowany nad Unix timestamp, gdy liczy się czytelność.

RFC 2822

Fri, 14 Mar 2025 15:37:12 +0000

Czytelny dla człowieka, ale niesortowalny. Używany głównie w nagłówkach e-mail (pole Date). Mniej zwarty niż ISO 8601 i Unix timestamp.

Data w formie czytelnej

14 marca 2025, 15:37

Najbardziej czytelny format dla użytkowników końcowych, ale niesortowalny i nieprzydatny do użycia programistycznego. Najlepszy do warstwy prezentacji UI.

Przykłady konwersji

Standardowy Unix timestamp (sekundy)

1741965432
2025-03-14T15:37:12Z

10-cyfrowy timestamp w sekundach — najpopularniejszy format używany w systemach Unix/Linux, w API systemu Unix, w JWT token i logach serwera. Ta konkretna wartość odpowiada Dniu Pi 2025 o godz. 15:37:12 UTC.

Timestamp Y2K — 1 stycznia 2000

946684800
2000-01-01T00:00:00Z

Unix timestamp odpowiadający momentowi Y2K: dokładnie 946 684 800 sekund po Unix epoch. To wygodna wartość kalibracyjna — jeśli konwerter zwraca dla niej 1 stycznia 2000, działa poprawnie.

Timestamp ujemny (przed epoch)

-86400
1969-12-31T00:00:00Z

Ujemne wartości Unix timestamp reprezentują daty sprzed 1 stycznia 1970. Wartość -86400 to dokładnie jeden dzień (86 400 sekund) przed epoch, co odpowiada 31 grudnia 1969 o północy UTC. Nie wszystkie systemy obsługują ujemne timestamp, ale ten konwerter radzi sobie z nimi prawidłowo.

Timestamp w milisekundach (13 cyfr)

1741965432000
2025-03-14T15:37:12.000Z

13-cyfrowy timestamp w milisekundach — natywny format `Date.now()` w JavaScript, `System.currentTimeMillis()` w Javie i większości nowoczesnych REST API. To ten sam moment co w pierwszym przykładzie, pomnożony przez 1000. Auto-detekcja rozpoznaje 13-cyfrową długość i poprawnie interpretuje wartość jako milisekundy.

Jak skonwertować Unix timestamp na datę

  1. 1

    Wybierz kierunek konwersji

    Wybierz „Timestamp → Data”, aby zdekodować Unix timestamp na czytelną datę, lub „Data → Timestamp”, by skonwertować datę i godzinę kalendarzową na Unix timestamp.

  2. 2

    Wpisz wartość

    Wklej lub wpisz Unix timestamp (np. 1741965432 lub 1741965432000) w polu wejściowym. Narzędzie automatycznie rozpozna, czy chodzi o sekundy, milisekundy czy mikrosekundy. W trybie Data → Timestamp wybierz rok, miesiąc, dzień, godzinę, minutę i sekundę za pomocą wybieraka daty.

  3. 3

    Skopiuj wynik konwersji

    Wynik od razu pojawia się w czasie UTC, czasie lokalnym, formacie ISO 8601 oraz w czasie relatywnym. Kliknij przycisk Kopiuj obok dowolnego formatu, aby skopiować go do schowka.

Typowe zastosowania

Tworzenie i debugowanie API
Dekodowanie nieprzejrzystych timestamp w odpowiedziach API, payload JWT token (claim iat, exp, nbf), danych zdarzeń webhook i wpisach logów. Szybka weryfikacja, czy token uwierzytelniający wygasł lub kiedy nastąpiło zdarzenie.
Przechowywanie i odpytywanie timestamp w bazie danych
Konwersja między Unix timestamp a datami czytelnymi dla człowieka przy pisaniu zapytań do bazy, przeglądaniu zapisanych rekordów albo walidacji, czy filtry zakresów dat w klauzulach WHERE są poprawnie określone.
Analiza i korelacja plików logów
Wiele logów systemowych i aplikacyjnych zapisuje zdarzenia jako Unix timestamp. Konwersja podejrzanych wpisów na czytelne czasy ułatwia korelację zdarzeń między usługami, identyfikację okien ataku oraz wskazanie dokładnego momentu wystąpienia błędu.
Weryfikacja wygaśnięcia JWT token
JSON Web Token kodują iat (issued at), exp (expires at) oraz nbf (not before) jako Unix timestamp w payload. Wystarczy wkleić te wartości wprost, aby zweryfikować okno ważności tokena bez ręcznego liczenia epoch.
Planowanie zadań cron
Można sprawdzić, czy harmonogramy cron, zaplanowane zadania i wyzwalacze czasowe pokrywają się z zamierzonymi oknami uruchomień, konwertując proponowane czasy startu na timestamp i z powrotem.
Koordynacja dat między strefami czasowymi
Unix timestamp jest z natury neutralny względem stref czasowych. Ten konwerter pomaga ustalić wspólny punkt odniesienia przy uzgadnianiu dat i terminów między zespołami w różnych strefach, potwierdzając ekwiwalent UTC dowolnego czasu lokalnego.

Informacje techniczne

Definicja Unix timestamp
Unix timestamp to liczba całkowita sekund, które upłynęły od Unix epoch: 1 stycznia 1970, 00:00:00 UTC (uniwersalny czas koordynowany). Wartość jest taka sama bez względu na lokalną strefę czasową obserwatora, co czyni z niej idealną, neutralną względem stref czasowych reprezentację do przechowywania i porównywania czasów.
Maksymalna wartość 32-bitowej liczby całkowitej ze znakiem
Maksymalna wartość 32-bitowej liczby całkowitej ze znakiem to 2 147 483 647. Jako Unix timestamp odpowiada 19 stycznia 2038 o godz. 03:14:07 UTC. Systemy przechowujące timestamp w 32-bitowych liczbach ze znakiem przepełnią się w tym momencie — to tzw. problem roku 2038. Systemy 64-bitowe potrafią reprezentować daty oddalone o miliardy lat w przyszłość.
JavaScript używa milisekund
Funkcje `Date.now()` oraz `new Date().getTime()` w JavaScript zwracają liczbę milisekund od epoch — nie sekund. Wynik to liczby 13-cyfrowe. Aby uzyskać standardowy Unix timestamp w sekundach, należy podzielić wartość przez 1000 i wziąć dolną granicę: `Math.floor(Date.now() / 1000)`. Wiele API i narzędzi oczekuje sekund, dlatego ten krok konwersji jest kluczowy.
Ujemne timestamp reprezentują daty sprzed epoch
Unix timestamp może być ujemny i wtedy oznacza datę sprzed 1 stycznia 1970. Na przykład -86400 reprezentuje 31 grudnia 1969 o godz. 00:00:00 UTC. Zakres timestamp 64-bitowego ze znakiem rozciąga się od około 292 miliardów lat przed epoch do 292 miliardów lat po niej — z dużym zapasem dla każdego praktycznego zastosowania.
Czas Unix nie uwzględnia sekund przestępnych
Czas Unix zakłada dokładnie 86 400 sekund na dobę (24 godziny × 60 minut × 60 sekund). W rzeczywistości IERS okresowo wstawia sekundy przestępne, aby utrzymać synchronizację UTC z obrotem Ziemi. Oznacza to, że czas Unix nie jest idealnie liniowy względem TAI (międzynarodowego czasu atomowego), a różnica narasta z czasem. Dla większości zastosowań ta rozbieżność jest nieistotna, jednak systemy precyzyjnego pomiaru czasu muszą ją uwzględniać.

Najlepsze praktyki obsługi timestamp

Zawsze przechowuj timestamp w UTC
Czas należy przechowywać w UTC (lub jako Unix timestamp) i konwertować na czas lokalny dopiero w warstwie wyświetlania. Mieszanie stref czasowych w bazie danych to częste źródło błędów trudnych do odtworzenia i naprawienia, zwłaszcza wokół przełomów czasu letniego.
Używaj precyzji milisekundowej dla nowoczesnych API
Większość nowoczesnych API, środowisk JavaScript i baz danych korzysta z milisekund (13-cyfrowy timestamp), a nie z sekund (10-cyfrowy timestamp). Przy integracji z zewnętrznymi systemami trzeba upewnić się co do oczekiwanej precyzji — przekazanie milisekund tam, gdzie spodziewane są sekundy, da datę oddaloną o około 11 000 lat w przyszłość.
Uważaj na problem roku 2038
Systemy przechowujące Unix timestamp w 32-bitowych liczbach całkowitych ze znakiem przepełnią się 19 stycznia 2038 o godz. 03:14:07 UTC. Należy zaudytować starsze systemy pod kątem 32-bitowych pól timestamp i zmigrować je do 64-bitowych liczb całkowitych albo łańcuchów ISO 8601. Nowoczesne języki i bazy danych domyślnie używają już 64-bitowych timestamp, ale systemy wbudowane, starsze bazy oraz systemy plików nadal mogą być narażone.
Nigdy nie polegaj na zegarze klienta w kontekście bezpieczeństwa
Zegar urządzenia klienta można ustawić na dowolną wartość — przypadkowo lub złośliwie. Nie należy używać timestamp dostarczonego przez klienta do logiki krytycznej dla bezpieczeństwa, takiej jak weryfikacja wygaśnięcia JWT, limitów sesji czy ograniczania liczby zapytań. Timestamp należy zawsze walidować po stronie serwera w oparciu o zaufane źródło czasu.
Używaj ISO 8601 do wymiany czytelnej dla człowieka
Gdy potrzebny jest format daty zarówno parsowalny maszynowo, jak i czytelny dla człowieka — na przykład w plikach logów, plikach konfiguracyjnych czy odpowiedziach API, do których zagląda programista — najlepszym wyborem jest ISO 8601 (np. 2025-03-14T15:37:12Z). Jest sortowalny leksykograficznie, jednoznaczny i obsługiwany praktycznie przez wszystkie nowoczesne parsery.

Najczęściej zadawane pytania

Dlaczego czas Unix zaczyna się 1 stycznia 1970?
Datę Unix epoch — 1 stycznia 1970 — wybrali twórcy Uniksa w Bell Labs pod koniec lat 60. jako wygodny, okrągły punkt startu, jednocześnie świeży i praktyczny obliczeniowo. W tamtym czasie timestamp przechowywano w 32-bitowych liczbach całkowitych, więc epoch musiała być wystarczająco bliska teraźniejszości, aby typowe daty mieściły się w rozsądnej wielkości liczbie. Rok 1970 był po prostu czystym, okrągłym rokiem przypadającym po rozpoczęciu prac nad systemem. Data 1 stycznia 1970 nie ma głębszego znaczenia technicznego — to inżynieryjny pragmatyzm. Inne systemy wybierały inne epoch: klasyczny toolbox Macintosha używał 1 stycznia 1904; Windows NT korzysta z 1 stycznia 1601; czas GPS startuje od 6 stycznia 1980. Każdy z nich odzwierciedla epokę i ograniczenia projektowe systemu, w którym powstał. Unix epoch zachowała się dlatego, że Unix stał się dominującym systemem operacyjnym, a każdy ważny język programowania, baza danych i system operacyjny ostatecznie przyjął czas Unix jako uniwersalny standard maszynowej reprezentacji timestamp. Dziś Unix epoch jest w istocie uniwersalną stałą w informatyce, rozpoznawaną przez każdą znaczącą platformę — od jąder Linuksa, przez silniki JavaScript, po bazy SQL. Wybór ten ma jedną dobrze znaną konsekwencję: daty sprzed 1 stycznia 1970 reprezentowane są liczbami ujemnymi, czego niektóre starsze systemy nie obsługują. W przypadku dat historycznych i obliczeń astronomicznych preferowane są czasem alternatywne formaty timestamp. Dla zdecydowanej większości tworzenia oprogramowania Unix epoch z powodzeniem pokrywa jednak wszystkie istotne daty.
Czym jest problem roku 2038?
Problem roku 2038 (zwany też Y2K38 lub Epokalipsą) to problem informatyczny dotykający systemy przechowujące Unix timestamp jako 32-bitowe liczby całkowite ze znakiem. 32-bitowa liczba ze znakiem może przyjmować wartości od -2 147 483 648 do 2 147 483 647. Interpretowana jako Unix timestamp, maksymalna wartość 2 147 483 647 odpowiada 19 stycznia 2038 o godz. 03:14:07 UTC. Sekundę później licznik przepełni się i przeskoczy na najmniejszą reprezentowalną wartość, odpowiadającą 13 grudnia 1901 — sprawiając, że takie systemy zaczną interpretować przyszłe daty jako odległą przeszłość. Skutki — od trywialnych do katastrofalnych — zależą od tego, jak timestamp są wykorzystywane. Systemy mogą odrzucać poprawne przyszłe daty w trakcie walidacji, błędnie sortować rekordy zależne od czasu, źle obliczać daty wygaśnięcia certyfikatów i token, a nawet ulegać awarii przy napotkaniu wartości przepełnionej. Rozwiązanie jest proste: migracja do 64-bitowych liczb całkowitych ze znakiem do przechowywania timestamp. 64-bitowy timestamp obejmuje zakres około 292 miliardów lat przed epoch i po niej — z ogromnym zapasem względem jakichkolwiek praktycznych potrzeb. Większość nowoczesnych systemów operacyjnych, języków programowania i baz danych już wewnętrznie używa 64-bitowych timestamp. Ryzyko tkwi w starszym kodzie, systemach wbudowanych, 32-bitowych systemach operacyjnych wciąż obecnych w produkcji, metadanych systemu plików (jak pola timestamp w FAT32) oraz kolumnach baz danych zdefiniowanych jako INT zamiast BIGINT. Programiści powinni zaudytować swoje systemy już teraz. Migracja z 32 do 64 bitów musi się dokonać przed 2038 rokiem, a w praktyce systemy z długoterminowymi rekordami (kredyty hipoteczne, infrastruktura, dokumenty prawne) mogą napotkać ten problem znacznie wcześniej, gdy przyszłe daty trafią do dotkniętych pól.
Czym różnią się timestamp w sekundach, milisekundach i mikrosekundach?
Unix timestamp występuje w trzech najczęstszych precyzjach, rozpoznawalnych po liczbie cyfr w wartości: **Sekundy (10 cyfr)**: oryginalny i najpopularniejszy format Unix timestamp. `1741965432` reprezentuje konkretną sekundę w czasie. Używany w: wywołaniach systemowych Unix/Linux (`time()`), większości narzędzi uniksowych, JWT token (claim `iat`, `exp`), header HTTP (`Last-Modified`) oraz wielu REST API. Aktualny timestamp ma długość około 10 cyfr. **Milisekundy (13 cyfr)**: precyzja jednej tysięcznej sekundy. `1741965432000` to ten sam moment, pomnożony przez 1000. Używane w: `Date.now()` w JavaScript, `System.currentTimeMillis()` w Javie, Node.js, większości nowoczesnych API JavaScript/TypeScript, Redis i wielu klientach baz danych. Gdy w odpowiedzi JSON widać 13-cyfrowy timestamp, to niemal na pewno milisekundy. **Mikrosekundy (16 cyfr)**: precyzja jednej milionowej sekundy. `1741965432000000` to ten sam moment pomnożony przez 1 000 000. Używane w: typach `TIMESTAMP` i `TIMESTAMPTZ` w PostgreSQL, w `time.time_ns()` w Pythonie (choć ta funkcja zwraca w istocie nanosekundy), w systemach handlu wysokich częstotliwości oraz w narzędziach analizy pakietów sieciowych. Najczęstszy błąd to mieszanie precyzji — np. przekazanie timestamp w milisekundach do funkcji oczekującej sekund. Daje to daty oddalone o około 11 574 lat w przyszłość. Zawsze warto sprawdzić w dokumentacji API lub systemu, jakiej precyzji się oczekuje, i traktować auto-detekcję tego konwertera jako szybkie potwierdzenie.
Czy czas Unix uwzględnia sekundy przestępne?
Nie — czas Unix nie uwzględnia sekund przestępnych i jest to jedno z jego znanych ograniczeń w zastosowaniach precyzyjnego pomiaru czasu. Sekundy przestępne są okresowo wstawiane (a teoretycznie również usuwane, choć dotąd żadnej nie usunięto) przez Międzynarodową Służbę Ruchu Obrotowego Ziemi i Systemów Odniesienia (IERS), aby utrzymać synchronizację UTC z lekko nieregularnym obrotem Ziemi. Do 2026 roku wstawiono 27 sekund przestępnych, począwszy od ich wprowadzenia w 1972 roku. Czas Unix zakłada idealnie regularny kalendarz z dokładnie 86 400 sekundami na dobę (24 × 60 × 60). Gdy wstawiana jest sekunda przestępna, w realnym świecie pojawia się sekunda, którą czas Unix ignoruje. Różne systemy operacyjne radzą sobie z tym inaczej: Linux tradycyjnie „rozmazuje” sekundę przestępną, spowalniając zegar w okolicy momentu wstawienia (podejście Google'a, zwane też „leap smearing”); niektóre systemy duplikują sekundę o 23:59:60 UTC; inne po prostu pomijają korektę i pozwalają zegarowi dryfować. Dla zdecydowanej większości zastosowań — usług webowych, API, baz danych, logiki biznesowej — skumulowane około 27 sekund różnicy z tytułu sekund przestępnych w ciągu ponad 50 lat jest całkowicie nieistotne. Różnica jest niezauważalna w jakichkolwiek aplikacjach skierowanych do użytkownika. Tam, gdzie sekundy przestępne mają znaczenie: synchronizacja GPS, obserwacje astronomiczne, sieciowe protokoły taktowania pakietów (PTP/IEEE 1588) oraz wszelkie systemy wymagające precyzyjnej korelacji Unix timestamp z TAI (międzynarodowym czasem atomowym). Jeśli aplikacja wpisuje się w te kategorie, należy korzystać z biblioteki obsługującej sekundy przestępne wprost lub operować bezpośrednio na timestamp TAI.
Czy Unix timestamp może być ujemny?
Tak, Unix timestamp może być ujemny, a ujemne wartości to legalny i jasno zdefiniowany sposób reprezentowania dat sprzed Unix epoch (1 stycznia 1970, 00:00:00 UTC). Każda sekunda przed epoch to dekrementacja o 1 od zera. Na przykład -1 oznacza 31 grudnia 1969 o godz. 23:59:59 UTC; -86400 reprezentuje 31 grudnia 1969 o godz. 00:00:00 UTC (dokładnie jeden dzień przed epoch); a -2208988800 odpowiada 1 stycznia 1900 o godz. 00:00:00 UTC. Większość nowoczesnych języków programowania i systemów operacyjnych obsługuje ujemne timestamp. `datetime.fromtimestamp(-86400)` w Pythonie poprawnie zwraca 31 grudnia 1969. `new Date(-86400 * 1000)` w JavaScript wyrenderuje tę samą datę. PostgreSQL przechowuje timestamp jako 8-bajtowe liczby całkowite i poprawnie obsługuje daty sprzed epoch oddalone o tysiące lat. Istnieją jednak istotne zastrzeżenia. Niektóre starsze systemy, biblioteki czy sterowniki baz danych mogą nie obsługiwać poprawnie ujemnych timestamp. Systemy 32-bitowe używające liczb bez znaku w ogóle nie potrafią reprezentować wartości ujemnych. Bazy danych z polami zdefiniowanymi jako UNSIGNED BIGINT lub DATETIME mogą odrzucać wartości ujemne lub interpretować je jako odległe daty w przyszłości. Dla dat historycznych (czegokolwiek sprzed 1970 roku) bezpieczniej jest często przechowywać datę jako łańcuch ISO 8601 lub korzystać z natywnego typu daty bazy danych, zamiast polegać na ujemnych Unix timestamp ze względu na przenośność. Ten konwerter prawidłowo obsługuje ujemne timestamp i wyświetli odpowiadającą im datę sprzed 1970 roku.
Jak pobrać aktualny Unix timestamp w JavaScript, Pythonie lub innych językach?
Pobranie aktualnego Unix timestamp jest proste w każdym ważnym języku programowania: **JavaScript / TypeScript:** ```javascript // Sekundy (większość API tego oczekuje) const seconds = Math.floor(Date.now() / 1000); // Milisekundy (natywnie w JavaScript) const milliseconds = Date.now(); ``` **Python:** ```python import time seconds = int(time.time()) # 1741965432 import datetime milliseconds = int(datetime.datetime.now(datetime.UTC).timestamp() * 1000) ``` **Go:** ```go import "time" seconds := time.Now().Unix() // int64 milliseconds := time.Now().UnixMilli() // int64 microseconds := time.Now().UnixMicro() // int64 ``` **Java:** ```java long seconds = System.currentTimeMillis() / 1000L; long milliseconds = System.currentTimeMillis(); // Lub z java.time (Java 8+): long seconds2 = Instant.now().getEpochSecond(); ``` **PHP:** ```php $seconds = time(); // integer $milliseconds = round(microtime(true) * 1000); ``` **Ruby:** ```ruby seconds = Time.now.to_i milliseconds = (Time.now.to_f * 1000).to_i ``` **Bash / Shell:** ```bash date +%s # sekundy date +%s%3N # milisekundy (GNU date) ``` Najważniejsze do zapamiętania jest to, że JavaScript natywnie pracuje w milisekundach, podczas gdy praktycznie każdy inny język domyślnie używa sekund. Zawsze należy jednoznacznie określić używaną precyzję i udokumentować ją w kontraktach API, aby zapobiec błędom integracji.
Jak skonwertować czas epoch na datę czytelną dla człowieka?
Są trzy szybkie sposoby konwersji czasu epoch (Unix timestamp) na datę czytelną dla człowieka: **1. Użyj tego konwertera online (najszybciej)** Wklej swój timestamp epoch w polu wejściowym powyżej. Narzędzie samo wykryje, czy chodzi o sekundy, milisekundy czy mikrosekundy, i natychmiast pokaże wynik w UTC, lokalnej strefie czasowej, formacie ISO 8601 oraz w czasie relatywnym. Kliknij Kopiuj, aby przejąć dowolny format. **2. Użyj kodu** W JavaScript: `new Date(1741965432 * 1000).toISOString()` zwraca `'2025-03-14T15:37:12.000Z'`. W Pythonie: `from datetime import datetime, UTC; datetime.fromtimestamp(1741965432, UTC)` zwróci ten sam wynik. Trzeba pamiętać, że JavaScript oczekuje milisekund, a Python sekund — to najczęstsze źródło błędów konwersji. **3. Użyj wiersza poleceń** Na Linuksie lub macOS z GNU date: `date -d @1741965432` (Linux) lub `date -r 1741965432` (macOS). W PowerShell na Windows: `[DateTimeOffset]::FromUnixTimeSeconds(1741965432).DateTime`. Wszystkie trzy metody dają ten sam wynik. Konwerter online powyżej to najszybsza opcja, gdy potrzebna jest błyskawiczna odpowiedź bez otwierania terminala czy pisania kodu.
Jaki jest aktualny Unix timestamp?
Aktualny Unix timestamp wyświetla się w zegarze na żywo u góry tej strony, aktualizując się co sekundę. Unix timestamp to po prostu liczba sekund od 1 stycznia 1970 00:00:00 UTC, rosnąca dokładnie o 1 co sekundę. Aby pobrać aktualny timestamp programowo: - **JavaScript**: `Math.floor(Date.now() / 1000)` (sekundy) lub `Date.now()` (milisekundy) - **Python**: `import time; int(time.time())` - **Bash**: `date +%s` W 2026 roku aktualny Unix timestamp znajduje się w okolicach 1,77 miliarda (10 cyfr). Wartość 2 miliardy zostanie osiągnięta około maja 2033 roku, a maksymalna wartość dla systemów 32-bitowych (2 147 483 647) zostanie osiągnięta 19 stycznia 2038 o godz. 03:14:07 UTC — to tzw. problem roku 2038. Wystarczy dodać tę stronę do zakładek, aby aktualny czas epoch zawsze mieć o jedno kliknięcie.
Muszę zdebugować timestamp w odpowiedzi mojego API — jak go skonwertować?
Skopiuj wartość timestamp z odpowiedzi API (zwykle to 10- lub 13-cyfrowa liczba w polu JSON typu „created_at” albo „timestamp”). Wklej ją wprost w polu wejściowym powyżej — narzędzie samo wykryje, czy chodzi o sekundy czy milisekundy, i natychmiast pokaże datę UTC, czas lokalny oraz format ISO 8601. Jeśli timestamp znajduje się wewnątrz JWT token, najpierw zdekoduj payload tokena (zakodowany w Base64URL), aby wyciągnąć pola iat, exp lub nbf, a następnie wklej te wartości tutaj. Do debugowania wsadowego pomocny jest fragment kodu: `new Date(timestamp * 1000).toISOString()` w konsoli przeglądarki — pozwala szybko sprawdzić wiele timestamp bez wychodzenia z narzędzi developerskich.
Jak pobrać aktualny Unix timestamp w Pythonie / JavaScript / Go?
W JavaScript użyj `Math.floor(Date.now() / 1000)` dla sekund lub `Date.now()` dla milisekund. W Pythonie użyj `import time; int(time.time())` dla sekund albo `int(time.time() * 1000)` dla milisekund. W Go użyj `time.Now().Unix()` dla sekund, `time.Now().UnixMilli()` dla milisekund lub `time.Now().UnixMicro()` dla mikrosekund. Trzeba pamiętać, że JavaScript natywnie pracuje w milisekundach, podczas gdy Python i Go domyślnie zwracają sekundy — to zdecydowanie najczęstsze źródło błędów timestamp przy integracji systemów napisanych w różnych językach. Zawsze należy udokumentować w specyfikacji OpenAPI/Swagger, jakiej precyzji oczekuje API.
Co dzieje się z Unix timestamp przy zmianach czasu letniego?
Unix timestamp jest całkowicie odporny na zmiany czasu letniego (DST), ponieważ opiera się na UTC, który nie podlega DST. Gdy w lokalnej strefie czasowej zegary „przeskakują do przodu” lub „cofają się”, Unix timestamp dalej rośnie dokładnie o 1 co sekundę — bez luk i bez powtórzeń. To jedna z kluczowych zalet przechowywania czasów jako Unix timestamp zamiast lokalnych łańcuchów daty/godziny. Przy konwersji Unix timestamp na czas lokalny w trakcie przejścia DST może się natomiast zdarzyć, że ten sam czas lokalny odpowiada dwóm różnym Unix timestamp (w godzinie cofnięcia, gdy zegary się powtarzają). Należy więc zawsze przechowywać i porównywać timestamp w UTC, a na czas lokalny konwertować wyłącznie na potrzeby wyświetlania.
Mam timestamp w milisekundach — jak go skonwertować na sekundy?
Podziel timestamp w milisekundach przez 1000 i odrzuć część dziesiętną. W JavaScript: `Math.floor(ms / 1000)`. W Pythonie: `ms // 1000` (dzielenie całkowite). Na przykład 1741965432000 (milisekundy) staje się 1741965432 (sekundy). Timestamp w milisekundach rozpoznasz po długości 13 cyfr, w przeciwieństwie do 10-cyfrowych timestamp w sekundach. To narzędzie samo wykrywa precyzję, więc można wkleić dowolny format wprost. Konwersja odwrotna (z sekund na milisekundy) to po prostu mnożenie przez 1000: 1741965432 × 1000 = 1741965432000. Trzeba uważać, by przypadkiem nie przekazać wartości w milisekundach do funkcji oczekującej sekund — wynikiem byłaby data oddalona o około 11 574 lat w przyszłość.

Powiązane narzędzia

Zobacz wszystkie narzędzia →