Převodník Unix epoch

Původ Unix time

Abychom epoch razítko — často nazývané Unix time, POSIX time nebo prostě epoch — opravdu pochopili, musíme se vrátit k počátkům operačního systému Unix na začátku 70. let. Unix time sleduje čas jako běžící součet sekund. Konkrétně představuje počet sekund, které uplynuly od Unix epoch. Samotná epocha je definována jako 00:00:00 Coordinated Universal Time (UTC) ve čtvrtek 1. ledna 1970.

Když Ken Thompson a Dennis Ritchie vyvíjeli první verze Unixu v Bell Labs, potřebovali jednoduchý a efektivní způsob, jak počítače reprezentují a ukládají data a časy. Lidsky čitelná data (jako „29. července 2026“) jsou pro počítače extrémně složitá: nepravidelné měsíce (28, 29, 30 nebo 31 dní), přestupné roky, časové zóny a přechody na letní čas. Tím, že čas vyjádřili jediným, nepřetržitě narůstajícím celým číslem, vytvořili univerzální a jednoznačný časový standard, který lze snadno ukládat, porovnávat a matematicky manipulovat.

Proč vývojáři používají epoch razítka dodnes

I po desetiletích zůstává Unix time páteří moderní výpočetní infrastruktury. Důvody univerzálního přijetí:

1. Jednoduchost a efektivita: Uložení 32bitového nebo 64bitového integeru zabere podstatně méně místa na disku i v paměti než formátovaný řetězec data. Když databáze obsahují miliardy záznamů, ušetřené bajty na řádek znamenají masivní snížení nákladů na úložiště a rychlejší indexy.
2. Nezávislost na časové zóně: Epoch razítko je inherentně vázané na UTC. Nezáleží, kde uživatel fyzicky je. Když server v Tokiu komunikuje s klientem v New Yorku, přenos epoch integeru zabrání zmatkům ohledně časových zón. Klient integer po přijetí jen převede do své místní zóny.
3. Snadné matematické operace: Trvání mezi dvěma událostmi spočítáte odečtením jednoho razítka od druhého. Kolik sekund uplynulo mezi dvěma záznamy v logu? timestamp2 - timestamp1 dá přesnou odpověď okamžitě, bez složitého parsování data.
4. Řazení v databázi: Chronologické řazení záznamů podle integer sloupce je pro databázové enginy výrazně rychlejší než parsování a řazení textových razítek.

Dopad přestupných sekund

Technická nuance Unix time spočívá v tom, jak zachází s přestupnými sekundami. Přestupná sekunda je jednosekundová úprava, která se občas aplikuje na Coordinated Universal Time (UTC), aby denní čas zůstal blízko střednímu slunečnímu času. Unix time přestupné sekundy nezohledňuje. V systému Unix time je každý den považován za přesně 86 400 sekund. Když nastane přestupná sekunda, Unix hodiny v podstatě zopakují tutéž sekundu dvakrát. Toto záměrné rozhodnutí brání nepředvídatelnosti razítek, zároveň ale znamená, že Unix time není striktně lineární mírou fyzického času od roku 1970. Pro naprostou většinu softwarových aplikací je tato drobná odchylka zcela přijatelná a výhodnější než složitost evidence každé historické přestupné sekundy.

Převod epoch razítka na lidsky čitelné datum patří k nejběžnějším úkolům vývojáře. Ať ladíte serverové logy, stavíte uživatelské rozhraní, nebo analyzujete databázové záznamy, tento převod je zásadní. Protože Unix time je univerzální standard, prakticky každý moderní jazyk nabízí vestavěné knihovny a funkce. Níže uvádíme podrobné příklady, jak převést standardní 10místné epoch razítko (v sekundách) na čitelný řetězec data v několika oblíbených jazycích.

JavaScript / Node.js

V JavaScriptu čas obsluhuje nativní objekt Date. Je ale zásadní pamatovat, že konstruktor Date očekává milisekundy, nikoli sekundy. Standardní Unix razítko proto musíte vynásobit 1000.

// Unix timestamp in seconds
const unixTimestamp = 1672531200;

// Convert to milliseconds by multiplying by 1000
const dateObject = new Date(unixTimestamp * 1000);

// Output in local time zone
console.log(dateObject.toLocaleString()); 
// Example output: '12/31/2022, 7:00:00 PM'

// Output in UTC
console.log(dateObject.toUTCString());
// Example output: 'Sun, 01 Jan 2023 00:00:00 GMT'

Python

Vestavěný modul datetime v Pythonu dělá tento proces velmi přímočarý. Metoda fromtimestamp() bere razítko v sekundách a vrací lokální datetime objekt, zatímco utcfromtimestamp() vrací UTC datetime objekt.

import datetime

unix_timestamp = 1672531200

# Convert to local time
local_time = datetime.datetime.fromtimestamp(unix_timestamp)
print(local_time.strftime('%Y-%m-%d %H:%M:%S'))

# Convert to UTC
utc_time = datetime.datetime.utcfromtimestamp(unix_timestamp)
print(utc_time.strftime('%Y-%m-%d %H:%M:%S'))

PHP

PHP má dlouhou tradici vynikajících nástrojů pro práci s datem a časem. Standardní funkce date() umožní formátovat Unix razítko přímo jako druhý argument.

$unix_timestamp = 1672531200;

// Convert and format the timestamp
$readable_date = date('Y-m-d H:i:s', $unix_timestamp);

echo $readable_date;

Java

V moderní Javě (Java 8 a novější) je doporučený balíček java.time. Třída Instant reprezentuje konkrétní okamžik na časové ose.

import java.time.Instant;
import java.time.ZoneId;
import java.time.format.DateTimeFormatter;
import java.time.ZonedDateTime;

public class EpochConverter {
    public static void main(String[] args) {
        long unixTimestamp = 1672531200L;
        
        // Create an Instant from seconds
        Instant instant = Instant.ofEpochSecond(unixTimestamp);
        
        // Convert to a specific time zone (e.g., UTC)
        ZonedDateTime dateTime = ZonedDateTime.ofInstant(instant, ZoneId.of("UTC"));
        
        // Format the output
        DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");
        System.out.println(dateTime.format(formatter));
    }
}

Go (Golang)

Balíček time v Go je robustní a velmi efektivní. Použijte funkci time.Unix(), která bere sekundy a nanosekundy jako argumenty.

package main

import (
	"fmt"
	"time"
)

func main() {
	unixTimestamp := int64(1672531200)
	
	// Convert timestamp (seconds, nanoseconds)
	t := time.Unix(unixTimestamp, 0)
	
	// Print in default format
	fmt.Println(t.Format(time.RFC3339))
}

Znalost těchto základních implementací vám umožní rychle napsat robustní logiku pro práci s časem, ať používáte jakýkoli tech stack.

V moderní éře webového vývoje a software engineeringu už ochrana dat a bezpečnost nejsou volitelné — jsou kritickými požadavky. Při hledání utilit jako převodník epoch vývojáři často nevědomky použijí nástroje, které jejich data ohrožují. Problém mnoha existujících online převodníků je architektura: spoléhají na zpracování na serveru. To znamená, že pokaždé, když vložíte razítko, JSON payload nebo kód do vstupních polí, data putují internetem na vzdálený server, zpracují se a vrátí se zpět.

Skrytá rizika nahrávání na server

Odeslání dat na neznámý server třetí strany zavádí vážné bezpečnostní zranitelnosti. I zdánlivě neškodné Unix razítko může být kontextově vysoce citlivé. Pokud ladíte kritický výpadek systému, bezpečnostní incident nebo analyzujete proprietární obchodní algoritmy, přesné časy těchto událostí jsou důvěrné. Při použití serverového nástroje zanecháváte digitální stopu na serveru, který neovládáte. Servery mohou logovat IP adresu, čas požadavku i přesná odeslaná data. V nejhorším případě mohou být data zachycena, uniknout při úniku, nebo se prodat datovým brokerům.

Výhoda Utiliome: 100% soukromé spuštění v prohlížeči

Právě proto je náš Převodník Unix epoch navržený jinak. Pevně věříme, že data by nikdy neměla opustit váš počítač. Nástroj běží zcela ve webovém prohlížeči pomocí JavaScriptu na straně klienta. Když vložíte razítko a převedete ho, matematické operace probíhají lokálně na CPU. Absolutně neprobíhá žádné nahrávání na server.

Toto architektonické rozhodnutí přináší několik zásadních výhod:

1. Nekompromisní soukromí: Protože se data našich serverů nikdy nedotknou, nemůžeme je logovat, ukládat ani vidět. S klidem převedete razítka související s citlivými interními incidenty, důvěrnými databázemi nebo soukromými uživatelskými logy, aniž byste porušili standardy shody (jako GDPR, HIPAA nebo SOC2).
2. Blesková rychlost: Serverové nástroje trpí síťovou latencí. Čekáte na DNS, HTTP požadavek do datacentra, zpracování a cestu zpět. Díky úplnému spuštění v prohlížeči poskytujeme okamžitou zpětnou vazbu v reálném čase. Při psaní probíhá převod v milisekundách.
3. Offline schopnost: Protože nástroj spoléhá výhradně na lokální prohlížeč, po načtení stránky funguje dál i bez internetového připojení.

Upřednostněním přístupu v prohlížeči bez nahrávání na server nabízíme 100% bezplatný nástroj, který respektuje soukromí a zrychluje workflow.

Unix time byla na svou dobu brilantní vynález, skrývá však masivní tikající bombu známou jako problém roku 2038, často dramaticky nazývaný „Epochalypse“. Abychom pochopili tuto hrozící technologickou krizi, musíme se podívat, jak se epoch čas ukládá v paměti počítače a jaké limity mají legacy hardware a software.

Omezení 32bitového integeru

Když Unix vznikal v 70. letech, úložiště a paměť byly extrémně drahé a omezené. Původní specifikace Unixu proto ukládala epoch čas jako signed 32bitový integer. V binárním počítání 32bitový integer alokuje 32 bitů (jedniček a nul) k reprezentaci čísla. Protože je „signed“, jeden bit určuje, zda je číslo kladné nebo záporné (což umožňuje reprezentovat data před 1. lednem 1970). Na samotnou velikost čísla zbývá 31 bitů.

Maximální kladná hodnota, kterou signed 32bitový integer unese, je přesně 2,147,483,647. 32bitové Unix hodiny proto dokážou počítat jen do 2 147 483 647 sekund po Unix epoch.

Co se stane 19. ledna 2038?

Když k Unix epoch (1. ledna 1970 v 00:00:00 UTC) přičteme 2 147 483 647 sekund, dojdeme k velmi konkrétnímu datu a času: úterý 19. ledna 2038 v 03:14:07 UTC.

Přesně v 03:14:08 UTC 32bitový integer přeteče. V informatice nastane integer overflow, když aritmetická operace zkusí vytvořit číselnou hodnotu větší, než je dostupné úložiště. Kvůli tomu, jak se signed integery v paměti zpracovávají (dvojkový doplněk), číslo „přeteče“ na nejnižší zápornou hodnotu: -2,147,483,648.

Místo správného času v roce 2038 dotčené počítače najednou interpretují čas jako záporný počet sekund od epoch a skočí zpět na pátek 13. prosince 1901.

Reálné důsledky

Důsledky tohoto přetečení mohou být katastrofální pro systémy, které se včas neupgradují. Software počítající budoucí data, finanční systémy spravující hypotéky nebo 30leté dluhopisy, vestavěné systémy v infrastruktuře a legacy databáze mohou úplně spadnout nebo produkovat divoce nepřesné výpočty. Když operační systém najednou věří, že je rok 1901, zabezpečené SSL/TLS certifikáty se jeví jako neplatné nebo ještě nevydané a internetová komunikace se rozpadne. Naplánované zálohovací skripty selžou a databázové transakce se mohou poškodit kvůli nemožným razítkům.

Jak se odvětví připravuje

Naštěstí je si softwarový průmysl problému Y2K38 vědom desítky let. Řešení je v teorii relativně jednoduché, ale globálně masivně složité: migrovat systémy na 64bitové integery pro ukládání času.

Signed 64bitový integer unese maximální hodnotu 9,223,372,036,854,775,807. V Unix time 64bitové hodiny nepřetečou dalších 292 miliard let — dlouho poté, co Slunce pohltí Zemi. Moderní operační systémy (64bitový Linux, Windows a macOS), moderní runtime programovacích jazyků a aktualizované souborové systémy už na 64bitová razítka přešly. Skutečné nebezpečí tkví ve vestavěných systémech, legacy IoT zařízeních, starém automobilovém softwaru a neudržovaných legacy kódových bázích, které je těžké nebo nemožné záplatovat. S blížícím se rokem 2038 musí vývojáři aktivně auditovat databáze, API a datové struktury, aby byly plně 64bitově kompatibilní.