Jak przekonwertować znacznik czasu Unix na datę: kompletny przewodnik dla programistów

Jeśli kiedykolwiek wpatrywałeś się w liczbę typu 1717200000 i zastanawiałeś się, jaką datę reprezentuje, nie jesteś sam. Nauka konwersji znacznika czasu Unix na datę to podstawowa umiejętność dla programistów pracujących z API, bazami danych i systemami backendowymi. Znacznik czasu Unix to po prostu liczba sekund (lub milisekund), które upłynęły od 1 stycznia 1970 roku o godzinie 00:00:00 UTC - punktu odniesienia znanego jako epoka Unix. Ten przewodnik przeprowadzi Cię przez mechanizmy konwersji dat i czasu, obsługę stref czasowych oraz praktyczne przykłady kodu w JavaScript, Python i SQL, dzięki czemu przestaniesz zgadywać i zaczniesz konwertować z pewnością siebie.

Czym jest znacznik czasu Unix?

Znacznik czasu Unix reprezentuje pojedynczy, jednoznaczny moment w czasie jako liczbę całkowitą. Zegar zaczął tykać 1 stycznia 1970 roku o godzinie 00:00:00 UTC - moment nazywany "epoką 0". Każda sekunda, która upłynęła od tego czasu, dodaje jeden do licznika. Ta prostota to dokładnie powód, dla którego stał się uniwersalnym formatem czasu dla systemów komputerowych.

W samej liczbie nie ma miesięcy, lat przestępnych ani korekt czasu letniego. Znacznik czasu jest zawsze oparty na UTC, co oznacza, że ta sama liczba odnosi się do dokładnie tego samego momentu w czasie, niezależnie od tego, gdzie znajduje się serwer lub użytkownik. To jednocześnie jego największa zaleta i źródło większości problemów programistów z obsługą formatów czasu.

Aby głębiej zrozumieć, jak czas epoki stał się podstawą nowoczesnej informatyki, zobacz nasz artykuł o Czasie epoki: podstawie znaczników czasu Unix.

Jedno ważne rozróżnienie: nie wszystkie znaczniki czasu Unix liczą w sekundach. Niektóre systemy, szczególnie środowiska JavaScript i wiele REST API, używają milisekund. Znacznik czasu 1717200000 jest w sekundach; 1717200000000 to ten sam moment w milisekundach. Pomylenie tych jednostek to najczęstszy błąd w konwersji dat i czasu. Zanim napiszesz pierwszą linię kodu, upewnij się, jaką jednostkę używa Twoje źródło.

Nie jesteś pewien, jakiej jednostki powinien używać Twój system? Sprawdź Sekundy vs milisekundy vs mikrosekundy: który znacznik czasu Unix wybrać? po praktyczne omówienie.

Obsługa stref czasowych i częste błędy przesunięć

Konwersja stref czasowych Unix to miejsce, gdzie większość programistów się potyka. Sam znacznik czasu jest zawsze w UTC. Strefa czasowa ma znaczenie tylko wtedy, gdy wyświetlasz lub interpretujesz ten znacznik czasu dla użytkownika lub wpisu w logu. Zrozumienie tego rozróżnienia zapobiega całej kategorii błędów.

Podstawy UTC

RFC 3339 definiuje standardowy format reprezentowania dat i czasu UTC w tekście (2024-06-01T00:00:00Z). Gdy konwertujesz znacznik czasu Unix na czytelny dla człowieka ciąg znaków, stosujesz przesunięcie strefy czasowej do bazy UTC. Dodatnie przesunięcie jak +05:30 (czas standardowy Indii) dodaje godziny i minuty; ujemne przesunięcie jak -05:00 (wschodni czas standardowy USA) je odejmuje.

Automatyczne wykrywanie strefy czasowej

Większość nowoczesnych języków i przeglądarek może automatycznie wykrywać lokalną strefę czasową. W JavaScript Intl.DateTimeFormat().resolvedOptions().timeZone zwraca nazwę strefy czasowej IANA (na przykład America/New_York). W Python moduł zoneinfo (Python 3.9+) obsługuje strefy IANA natywnie. Poleganie na automatycznym wykrywaniu jest w porządku do celów wyświetlania, ale nigdy nie polegaj na tym przy przechowywaniu lub obliczaniu znaczników czasu.

Częste błędy przesunięć

• Traktowanie czasu lokalnego jako UTC: Jeśli Twój serwer jest ustawiony na UTC+2 i wywołujesz datetime.now() bez określenia strefy czasowej, otrzymujesz czas lokalny, który wygląda jak UTC, ale jest przesunięty o dwie godziny.
• Przejścia czasu letniego (DST): Stałe przesunięcie jak +01:00 nie uwzględnia czasu letniego. Używaj nazwanych stref IANA (Europe/Berlin) zamiast stałych przesunięć, gdy tylko to możliwe.
• Niezgodność milisekund vs sekund: Przekazanie znacznika czasu w milisekundach do funkcji oczekującej sekund produkuje datę z roku 55000+. Zawsze najpierw sprawdź wielkość liczby.
• Ustawienia strefy czasowej bazy danych: MySQL i PostgreSQL mogą przechowywać i wyświetlać znaczniki czasu różnie w zależności od strefy czasowej sesji. Przechowuj znaczniki czasu w UTC i konwertuj w warstwie aplikacji.

Przykłady kodu: JavaScript, Python i SQL

Poniższe fragmenty kodu obejmują najczęstsze scenariusze konwersji Unix na datę. Każdy przykład używa konkretnego znacznika czasu: 1717200000, który odpowiada 1 czerwca 2024, 00:00:00 UTC.

JavaScript: konwersja znacznika czasu Unix

Obiekt Date w JavaScript pracuje w milisekundach, więc najpierw pomnóż znacznik czasu oparty na sekundach przez 1000.

// JavaScript konwersja znacznika czasu unix na datę
const unixSeconds = 1717200000;
const date = new Date(unixSeconds * 1000); // konwersja na milisekundy

// Ciąg UTC
console.log(date.toUTCString());
// Wynik: "Sat, 01 Jun 2024 00:00:00 GMT"

// Wyświetlanie lokalnej strefy czasowej (używa strefy czasowej przeglądarki/systemu)
console.log(date.toLocaleString("pl-PL", { timeZone: "Europe/Warsaw" }));
// Wynik: "1.06.2024, 02:00:00"

// Format ISO 8601
console.log(date.toISOString());
// Wynik: "2024-06-01T00:00:00.000Z"

Zauważ, jak ten sam znacznik czasu wyświetla się jako różne godziny w Warszawie, ponieważ północ UTC to 2:00 w czasie środkowoeuropejskim letnim. To nie jest błąd; to poprawne zachowanie konwersji strefy czasowej Unix.

Python: znacznik czasu Unix na datę i czas

Moduł datetime w Python zapewnia czyste, jawne metody. Zawsze używaj obiektów datetime świadomych strefy czasowej w kodzie produkcyjnym.

from datetime import datetime, timezone
from zoneinfo import ZoneInfo  # Python 3.9+

unix_seconds = 1717200000

# Python znacznik czasu unix na datę i czas (UTC)
dt_utc = datetime.fromtimestamp(unix_seconds, tz=timezone.utc)
print(dt_utc)
# Wynik: 2024-06-01 00:00:00+00:00

# Konwersja do konkretnej strefy czasowej
dt_warsaw = dt_utc.astimezone(ZoneInfo("Europe/Warsaw"))
print(dt_warsaw)
# Wynik: 2024-06-01 02:00:00+02:00

# Formatowanie jako czytelny ciąg znaków
print(dt_utc.strftime("%d %B %Y o %H:%M UTC"))
# Wynik: 01 June 2024 o 00:00 UTC

Używanie datetime.fromtimestamp() bez argumentu tz zwraca naiwny (nieświadomy strefy czasowej) datetime w lokalnym czasie systemowym, co może powodować ciche błędy w środowiskach serwerowych. Zawsze przekazuj tz=timezone.utc jako nawyk.

SQL: epoka na datę i czas

Zarówno PostgreSQL, jak i MySQL obsługują bezpośrednią konwersję epoki na datę i czas.

-- PostgreSQL: konwersja znacznika czasu unix na datę
SELECT TO_TIMESTAMP(1717200000) AS converted_date;
-- Wynik: 2024-06-01 00:00:00+00

-- MySQL: konwersja unix na datę
SELECT FROM_UNIXTIME(1717200000) AS converted_date;
-- Wynik: 2024-06-01 00:00:00
-- Uwaga: FROM_UNIXTIME używa strefy czasowej sesji. Ustaw ją jawnie:
SET time_zone = '+00:00';
SELECT FROM_UNIXTIME(1717200000);

Po głębsze wskazówki dotyczące przechowywania i odpytywania znaczników czasu w bazach danych, zobacz Znaczniki czasu Unix w bazach danych: najlepsze praktyki przechowywania i zapytań.

Typowe przypadki użycia: epoka na datę w rzeczywistych systemach

Zrozumienie mechanizmów to jedno. Zobaczenie, jak konwersja epoki na datę działa w rzeczywistych systemach, sprawia, że wiedza się utrwala. Oto trzy konkretne scenariusze zaczerpnięte z typowych wzorców rozwoju SaaS.

Studium przypadku: parsowanie REST API, przechowywanie w bazie danych i logowanie backendu

Wyobraź sobie platformę analityczną SaaS, która pobiera zdarzenia z zewnętrznego REST API. Każda odpowiedź API zawiera pole typu "event_time": 1717200000. Oto jak zespół obsługuje to na każdej warstwie:

1. Parsowanie REST API
Usługa backendowa otrzymuje ładunek JSON i natychmiast waliduje jednostkę znacznika czasu. Ponieważ wartość ma 10 cyfr, zespół potwierdza, że jest w sekundach (13 cyfr wskazywałoby na milisekundy). Usługa Python konwertuje to na obiekt datetime świadomy UTC przed jakimkolwiek dalszym przetwarzaniem. To zapewnia, że funkcje downstream nigdy nie otrzymają surowej liczby całkowitej przez przypadek.

2. Przechowywanie w bazie danych
Platforma przechowuje wartość w kolumnie PostgreSQL typu TIMESTAMPTZ (znacznik czasu ze strefą czasową). Aplikacja zawsze wstawia w UTC używając TO_TIMESTAMP(1717200000). Przechowywanie w UTC oznacza, że gdy firma rozszerza się na obsługę użytkowników w wielu regionach, nie jest potrzebna migracja danych. Zapytania zawsze filtrują w UTC i konwertują na czas lokalny tylko w warstwie prezentacji.

3. Logowanie backendu
Pipeline logowania dołącza ciąg ISO 8601 UTC (2024-06-01T00:00:00Z) do każdego wpisu w logu obok surowego znacznika czasu Unix. To podwójne podejście oznacza, że inżynierowie mogą czytać logi bezpośrednio bez narzędzia konwersji, podczas gdy zautomatyzowane systemy monitorowania nadal mogą wykonywać precyzyjne obliczenia na wartościach całkowitych. Gdy raport o błędzie mówi "błąd wystąpił około 9 rano czasu tokijskiego", zespół konwertuje to na zakres znaczników czasu Unix i odpytuje logi bezpośrednio.

Ten trzywarstwowy wzorzec (parsuj, przechowuj w UTC, wyświetlaj lokalnie) to najczystszy sposób obsługi konwersji dat i czasu w każdym systemie produkcyjnym.

Podsumowanie

Konwersja znacznika czasu Unix na czytelną datę jest prosta, gdy zrozumiesz trzy zasady: znacznik czasu jest zawsze w UTC, jednostka to sekundy lub milisekundy (potwierdź przed konwersją), a przesunięcia stref czasowych stosuje się w czasie wyświetlania, nie przechowywania. Niezależnie od tego, czy piszesz w JavaScript, Python czy SQL, wbudowane narzędzia są niezawodne, o ile używasz ich z jawnymi argumentami strefy czasowej. Zastosuj trzywarstwowy wzorzec ze studium przypadku powyżej (parsuj, przechowuj w UTC, wyświetlaj lokalnie), a unikniesz najczęstszych pułapek w konwersji dat i czasu w każdym systemie SaaS.

Konwertuj dowolny znacznik czasu Unix natychmiast

Wklej dowolny znacznik czasu i otrzymaj dokładną datę UTC, czas lokalny i podział stref czasowych jednym kliknięciem. Bez konfiguracji, bez rejestracji.

Wypróbuj darmowy konwerter na unixtimestamp.app →