Průvodce vývojáře k převodníku Unixového časového razítka

A převaděč unixového časového razítka je jeden z těch jednoduchých, ale nezbytných nástrojů, které jako vývojář nebo analytik dat budete neustále potřebovat. Je to užitečný nástroj, který překládá dlouhé, zdánlivě náhodné číslo do data a času, kterým skutečně rozumíme. Tento překlad je zásadní, když prohledáváte systémové logy, pracujete s API nebo provádíte dotazy na databáze, kde je čas uložen v tomto super-efektivním formátu.

Co je unixové časové razítko a proč je důležité

Než můžete skutečně ocenit dobrý převaděč, musíte pochopit, co to to číslo vlastně je. Ve svém jádru je unixové časové razítko pouze průběžným počítáním sekund. Sleduje celkový počet sekund, které uplynuly od 00:00:00 UTC 1. ledna 1970. Ten konkrétní okamžik v čase je proslulý jako „unixová epocha“.

Proč tedy tato metoda? Jednoduchost a efektivita. Ukládání času jako jednoho celého čísla je mnohem kompaktnější a výkonnější než obšírný řetězec jako „Pátek, 1. ledna 2021 12:00:00 AM GMT“. To z něj dělá ideální řešení pro několik klíčových oblastí:

• Uložení v databázi: Časová razítka jsou malá, takže je lze rychle indexovat a prohledávat. Je to obrovská výhra pro výkon.
• Zátěž v API: Odesílání jednoho čísla tam a zpět je na šířku pásma mnohem méně náročné než odesílání kompletního řetězce s datem, což vede k rychlejší odezvě.
• Logovací soubory: Když parsujete logy z desítek různých systémů, mít jednotné, na jazyce nezávislé časové razítko je spása.
• Výpočty: Potřebujete vědět, jak dlouho proces trval? Stačí odečíst časové razítko začátku od časové razítka konce. Je to jednoduchá matematika s celými čísly.

Sekundy vs. Milisekundy a dále

Klasické unixové časové razítko je 10ciferné číslo reprezentující sekundy. Jak se ale technologie vyvíjela, rostla i potřeba přesnějšího měření času. Právě zde začnete vidět různé délky časových razítek a je to běžný kámen úrazu.

Zde je rychlý přehled toho, co běžně v praxi narazíte. Záměna jednoho za druhé je klasická chyba „o tisíc“, která může vést k velmi matoucím chybám.

Běžné formáty unixového časového razítka na první pohled

Jednotka	Počet číslic	Typický případ použití	Příklad hodnoty (pro stejný okamžik)
Sekundy	10	Standard pro většinu backendových systémů, databází a API.	1609459200
Milisekundy	13	Velmi běžné v webových technologiích, zejména JavaScript.	1609459200000
Mikrosekundy	16	Používá se ve vysokofrekvenčním obchodování nebo vědeckých výpočtech.	1609459200000000

Správné pochopení těchto formátů je klíčové. Pokud nástroj očekává sekundy a vy mu předáte milisekundy, dostanete datum, které je tisíce let v budoucnosti. Je to chyba, kterou jsme všichni někdy udělali!

Proslulý problém roku 2038

Elegantní jednoduchost unixového časového razítka také vytiklá bombu: „Problém roku 2038“. Na starších 32bitových systémech se časová razítka ukládala jako znaménkem příznatelné 32bitové celé číslo. Problém je v tom, že tento typ celého čísla má strop – nemůže pojmout číslo větší než 2,147,483,647.

Dne 19. ledna 2038 ve 03:14:07 UTCpřekročí počet sekund od epochy tento limit. Když k tomu dojde, celé číslo se "převrátí" a stane se záporným číslem. To by způsobilo, že zranitelné systémy by datum interpretovaly jako návrat do 1901, což by mohlo způsobit pád miliard starších zařízení, která jsou stále v provozu. Více informací o Unix epochě a jejím dopadu získáte od odborníků ze společnosti StrongDM.

Naštěstí to není něco, o co se většina z nás musí starat denně. Většina moderních systémů přešla na 64-bitové celá čísla pro časové záznamy. 64-bitové celé číslo je tak obrovské, že nepřeteče dalších 292 miliard letčímž se problém účinně vyřeší natrvalo.

Přesto se jedná o fantastický kousek výpočetní historie a klíčový kus znalostí, pokud se někdy ocitnete při práci na starších vestavěných systémech nebo starších kódových základnách. Pochopení těchto základů činí z jakéhokoli převaděče Unixového časového razítka mnohem výkonnější nástroj ve vašich rukou.

Usnadněte si převody ve svém prohlížeči

Zatímco použití příkazu terminálu nebo úryvku kódu funguje, není to vždy nejrychlejší způsob, jak věci dokončit. Někdy prostě potřebujete odpověď. právě teď, aniž byste narušili své soustředění nebo přepínali okna. Právě zde se ukazuje hodnota dobrého nástroje v prohlížeči, zejména specializovaného převaděče Unixového časového razítka , který ž přímo ve vašem prohlížeči.

Skutečné kouzlo spočívá v udržení pracovního toku. Představte si to: prohrabáváte se odpovědí API v nástrojích pro vývojáře ve svém prohlížeči a narazíte na časové razítko. Místo otevírání dalšího panelu nebo spouštění terminálu stisknete rychlou klávesovou zkratku, vložíte číslo a okamžitě získáte odpověď. Přesně takový plynulý pracovní postup získáte s nástroji jako ShiftShift Extensions, které kombinují řadu užitečných utilit do jednoho Command Palette.

Získejte okamžité odpovědi pomocí klávesové zkratky

Vše se točí kolem rychlosti. S nástrojem jako ShiftShift stačí rychlé dvojité klepnutí Shift klávesa (nebo na Macu Cmd+Shift+P otevře příkazový panel. Stačí začít psát "timestamp," a převaděč se objeví. Vložte svou hodnotu a okamžitě máte čitelné datum.

Vypadá to takhle – Panel příkazů je připravený a čeká, aby převedl časové razítko přímo nad vaší aktuální stránkou.

Nejlepší je, jak se integruje, aniž by vás obtěžoval. Převaděč je jen jedním z mnoha nástrojů dostupných ve stejném překryvném panelu, takže nikdy nemusíte opustit to, co právě děláte.

Tento přístup je pro vývojáře, testery a kohokoli dalšího, kdo prakticky žije ve svém prohlížeči, spásou. Navíc převod probíhá zcela na vašem zařízení. Citlivá data z logů nebo odpovědí API nikdy neopustí váš počítač, což je obrovská výhra pro soukromí.

Schopnost převést časové razítko, přeformátovat nepořádný JSON blob a poté vypočítat časový rozdíl – vše z jednoho rozhraní – je obrovskou úsporou času. Proměňuje neohrabaný proces s více nástroji v jedinou plynulou akci.

Více než jen nástroj na jedno použití

Skvělý utilita v prohlížeči je zřídka jen jedním nástrojem; je součástí celého sady nástrojů. Často zjistíte, že převaděč časových razítek používáte spolu s dalšími funkcemi.

Například ho můžete zkombinovat s:

• A JSON nebo SQL formátovačem abyste před vytažením časového razítka vyčistili kód.
• A vestavěná kalkulačka pro rychlý výpočet hodnot epoch. (Můžete si pohrát s podobným nástrojem na stránce ShiftShift kalkulačka abyste viděli, jak to funguje).
• A nástroj na porovnávání textu který najde rozdíly mezi dvěma odpověďmi API, včetně časových razítek.

Mít všechny tyto potřebné nástroje na jednom místě vytváří mnohem rychlejší a sourodější pracovní postup. Nejde jen o pohodlí – jde o to eliminovat všechny ty drobné, opakující se přestávky, které se sčítají a ničí vaši produktivitu během celého dne.

Praktické převody časových značek v kódu

Pokud jste vývojář, víte, že práce s časovými značkami je prostě součástí práce. Ale buďme upřímní, syntaxe není nikdy úplně stejná od jednoho jazyka k druhému. Tato sekce je váš hlavní podváděcí list, plný úryvků kódu, které můžete okamžitě převzít a použít pro platformy, na kterých skutečně pracujete. Žádné další prohrabávání starých vláken na Stack Overflow – jen praktické příklady, které vás posunou vpřed.

Ať už zpracováváte data na webovém front-endu, píšete skript v Pythonu nebo se dotazujete databáze, převod epochálního času je základní dovednost. Projdeme si nejčastější scénáře, od převodu epochálního celého čísla na čitelný řetězec a pak zpět.

Převod časových razítek v JavaScriptu

Hlavním nástrojem zde je objekt Date v JavaScriptu, ale má jeden hlavní záludný rys, který vývojářům neustále působí potíže: pracuje v milisekundách, nikoli v sekundách. To je klasický zdroj chyb, když váš frontend komunikuje s backendem, který používá standardní 10místná, sekundová časová razítka.

Chcete-li správně převést standardní Unixové časové razítko (v sekundách) na objekt Date, musíte jej vynásobit 1000.

// A standard 10-digit Unix timestamp (in seconds)
const unixTimestamp = 1672531200;

// Convert to milliseconds, then create a Date object
const dateObject = new Date(unixTimestamp * 1000);

// Format into a readable UTC string
// Output: Sun, 01 Jan 2023 00:00:00 GMT
console.log(dateObject.toUTCString());

Potřebujete aktuální časové razítko? Date.now() vám ho poskytne v milisekundách. Jen si pamatujte, že před odesláním standardního 10místného časového razítka zpět do API jej musíte vydělit číslem 1000 a zaokrouhlit dolů.

Zpracování převodů v Pythonu

Na backendu je modul datetime v Pythonu velmi silný nástroj. Je neuvěřitelně flexibilní a má vynikající podporu pro převody s ohledem na časová pásma, což z něj činí spolehlivou volbu pro služby, které potřebují přesně zpracovávat čas v různých oblastech.

Zde je přímý způsob, jak převést časové razítko pomocí knihovny datetime:

import datetime

Standardní 10místné Unixové časové razítko

unix_timestamp = 1672531200

Převeďte časové razítko na objekt datetime

datetime_obj = datetime.datetime.fromtimestamp(unix_timestamp)

Naformátujte ho do čistého, lidsky čitelného řetězce

Výstup: 2023-01-01 00:00:00

print(datetime_obj.strftime('%Y-%m-%d %H:%M:%S'))
Tento jednoduchý přístup vám poskytne čistý a spolehlivý způsob, jak spravovat epochální čas ve vašich aplikacích v Pythonu. A pokud pracujete se složitými datovými strukturami jako JSON, které obsahují časová razítka, může se vám hodit náš průvodce použitím JSON formatéru pro ladění.

Převody v databázích pomocí SQL

Databáze často ukládají čas jako Unixová časová razítka, protože jsou efektivní. Dobrou zprávou je, že většina dialektů SQL má vestavěné funkce pro zpracování těchto převodů přímo uvnitř vašich dotazů. To je mnohem efektivnější než tahat surová celočíselná časová razítka a převádět je v kódu vaší aplikace.

Unixové časové razítko je téměř univerzální, používá se ve více než 90% programovacích jazycích – od Date.now() v JavaScriptu po time.time() v Pythonu – a pohání biliony denních operací. Správné nastavení časových pásem je klíčové; solidní převaděč unixových časových razítek zvládne více než 400 IANA zón, což pomáhá předcházet chybám v odhadovaných 62% globálních aplikacích, které časová pásma výslovně nespravují. Více podrobností o globálním přijetí těchto nástrojů najdete na Fossa.

Pro vývojáře je schopnost formátovat SQL, převádět časová razítka a počítat epochální rozdíly, aniž byste museli opustit svůj stroj, obrovským přínosem pro produktivitu. Tento přístup „nejprve lokálně“ vás také udrží v souladu s moderními standardy ochrany údajů, jako jsou GDPR a CCPA.

Příklad pro MySQL

V MySQL budete nejčastěji používat funkci FROM_UNIXTIME(). Přebírá epochální celé číslo a čistě ho převádí na standardní formát DATETIME.

SELECT FROM_UNIXTIME(1672531200);
-- Vrací: '2023-01-01 00:00:00'
Chcete-li jít opačným směrem – z řetězce s datem zpět na epochální časové razítko – použijte prostě UNIX_TIMESTAMP().

SELECT UNIX_TIMESTAMP('2023-01-01 00:00:00');
-- Vrací: 1672531200

Příklad pro PostgreSQL

PostgreSQL používá mírně odlišnou, ale stejně výkonnou funkci: to_timestamp(). Tato funkce přímo převádí unixové časové razítko na hodnotu TIMESTAMP WITH TIME ZONE.

SELECT to_timestamp(1672531200);
-- Vrací: 2023-01-01 00:00:00+00
Protože je od základu časově pásmově uvědomělá, je to velmi robustní volba pro aplikace sloužící globálnímu publiku, kde je přesnost času zásadní.

Zvládnutí převodů časových razítek v terminálu

Pokud žijete v příkazovém řádku, přepínání do prohlížeče nebo grafického rozhraní pro rychlý převod časového razítka je skutečným zabijákem pracovního postupu. Narušuje to prostě vaši koncentraci. Dobrá zpráva je, že nemusíte; jak Linux, tak macOS mají výkonné, nativní nástroje pro zpracování těchto převodů, aniž byste museli terminál opustit.

Primárním nástrojem pro toto je skromný příkaz date. Je prakticky na každém unixovém systému, ale je tu háček: syntaxe pro jeho použití jako unix timestamp convertor se liší mezi Linuxem (GNU) a macOS (BSD). Znát rozdíl je klíčem k tomu, abyste to pokaždé udělali správně.

Převody časových razítek na Linuxu

Na Linuxu je syntaxe čistá a snadno zapamatovatelná. Jednoduše použijete příznak -d k zadání data, ale musíte mu říct, že zadáváte epochu tím, že ji předchází symbolem @.

Řekněme, že procházíte logy a narazíte na časové razítko 1704067200. Abyste viděli, co to skutečně znamená, spustili byste toto:

date -d @1704067200

Okamžitě dostanete zpět lidsky čitelné datum, něco jako Mon Jan 1 00:00:00 UTC 2024. Tento výstup můžete také vyčistit vlastním formátem.

date -d @1704067200 +"%Y-%m-%d %H:%M:%S"

Výstup: 2024-01-01 00:00:00

Pro Tipy: Tento příkaz se stane skutečnou mocnou zbraní, když do něj začnete předávat jiné příkazy. Můžete grep časové razítko z obrovského logovacího souboru a přímo ho zadat do date pro okamžitý převod. Z mnohokrokového úkolu ladění se stane jednoduchý, elegantní příkaz na jeden řádek.

Zpracování převodů na macOS

Nyní, pokud spustíte stejný příkaz pro Linux na Macu, vyhodí chybu. BSD verze příkazu date, kterou macOS používá, vyžaduje místo toho příznak -r a nepotřebuje předponu @.

Jak byste převedli stejné časové razítko na Macu:

date -r 1704067200

Stejně jako verze pro Linux můžete přidat možnosti formátování, abyste získali přesný výstup, který chcete.

date -r 1704067200 +"%Y-%m-%d %T %Z"

Výstup: 2024-01-01 00:00:00 UTC

Tento malý rozdíl je klasickým kamenem úrazu pro každého, kdo se často přepíná mezi Linuxem a macOS. Zapamatování obou verzí vám v budoucnu ušetří spoustu starostí.

Jakmile tyto příkazy zvládnete, můžete převody časových razítek přímo zakomponovat do svých shell skriptů a analýzy logů. Je to malá dovednost, ale přičítá se k nějakým opravdovým ziskům produktivity, udržuje vás ve stavu soustředění a zaměření na důležitou práci.

Časté pasti s časovými razítky a jak se jim vyhnout

Práce s unixovými časovými razítky se na povrchu zdá přímočará, ale několik klasických chyb může vést k některým skutečně zuřivým chybám. Tyto problémy mají nepříjemný zvyk objevovat se daleko od místa, kde se chyba ve skutečnosti stala, což je činí opravdovou noční můrou při ladění. Považujte tuto sekci za svého průvodce v terénu pro rozpoznávání a obcházení nejčastějších pastí s časovými razítky, které jsem za ta léta viděl.

Záměna sekund a milisekund

Zdaleka nejčastější chybou je zaměňování sekund a milisekund. Standardní unixové časové razítko je 10místné celé číslo představující počet sekund od epochy. Ale mnoho systémů, zejména ve světě JavaScriptu, pracuje s 13místným časovým razítkem pro milisekundy. Když frontendová aplikace předá milisekundovou hodnotu backendu, který očekává sekundy, věci se zvrtnou.

Pro unix timestamp convertor, ten 13místný číselný kód vypadá jako datum v daleké budoucnosti. To může tiše narušit validaci dat, logiku plánování a jakékoli historické záznamy, které se snažíte vést. Jde o druh nenápadného poškození dat, kterého si možná nevšimnete ani několik týdnů.

Past na Časová pásma

Další úskalí, které nachytá i zkušené vývojáře, je zpracování časových pásem. Unixový časový kód ze své definice vždy odkazuje na Koordinovaný světový čas (UTC). Představuje jeden univerzální okamžik v čase, zcela nezávislý na místním čase. Nastražená past se projeví, když na to zapomenete a předpokládáte, že časový kód odráží místní čas uživatele.

Tato chyba se obvykle stane, když převádíte časový kód na čitelné datum bez zadání časového pásma. Systém často ve výchozím nastavení použije místní čas serveru, což vede k chaosu. Uživatel v New Yorku může vidět čas určený pro někoho v Londýně, ale liší se o několik hodin.

Zlaté pravidlo je jednoduché: v backendu vždy považujte časové kódy za UTC. Ukládejte je jako UTC, zpracovávejte jako UTC a na frontendu je převeďte na místní čas uživatele pouze bezprostředně před zobrazením.

Řešení běžných chyb při převodu časových kódů

Když se něco pokazí, příznaky mohou být matoucí. Zde je stručná tabulka, kterou jsem sestavil na základě zkušeností, aby vám pomohla diagnostikovat a opravit nejčastější problémy přímo na místě.

Příznak	Pravděpodobná příčina	Řešení
Datum je v roce 52361 nebo jiném vzdáleném budoucím roce.	Milisekundy vs. sekundy. Předáváte 13místný časový kód v milisekundách funkci, která očekává 10místný kód v sekundách.	Před zpracováním vydělte časový kód 1000. Vždy ověřujte počet číslic přijímaných časových kódů.
Čas se liší o několik hodin, ale datum je správné.	Chybné zpracování časového pásma. Časový kód byl převeden pomocí místního času serveru místo místního času uživatele nebo UTC.	Ujistěte se, že všechny převody explicitně specifikují cílové časové pásmo. Na klientovi převeďte na místní čas pouze bezprostředně před zobrazením.
Datum je zaseknuté na 1. lednu 1970.	Neplatný nebo nulový časový kód. Hodnota časového kodu je pravděpodobně 0, null nebo undefined.	Před pokusem o převod přidejte kontrolu, zda je časový kód platné kladné celé číslo. Nastavte záložní (fallback) hodnotu.
Zobrazuje se chyba „Neplatné datum“ nebo chyba NaN.	Nesprávný datový typ. Časový kód je zpracováván jako řetězec nebo jiný necíselný typ, zatímco je požadováno číslo.	Před použitím v datumových funkcích explicitně převeďte časový kód na celé číslo (parseInt() v JS, int() v Pythonu).

Pamatujte, rychlá kontrola vstupu vám může ušetřit hodiny následného ladění.

Vyhnutí se nejednoznačnosti pomocí standardních formátů

Spoléhání se na surové celočíselné časové kódy při přenosu dat mezi systémy může vést k zmatků. Proto je tak skvělým obranným tahem standardizace na univerzální řetězcový formát, jako je ISO 8601 (2022-05-17T12:00:00Z). Převod unixových časových kódů (např. 1652905200) do takového jasného, samodokumentujícího formátu pomáhá předcházet chybám v odhadovaných 37% přenosech dat přes různá časová pásma.

Vzhledem k tomu, že 72% společností z žebříčku Fortune 500 používá unixové časové kódy pro analýzu logů, kde jediná chyba může stát přes $10,000 za hodinu prostojů, je přesnost klíčová. Více o tom, jak je epoch čas využíván v různých odvětvích, si můžete přečíst na EpochConverter.

Pro ty, kteří spravují databáze, je konzistentní zpracování časových kódů stejně důležité. Pokud se často potýkáte s různými formáty časových kódů ve své databázi, náš průvodce používáním výkonného SQL formátovače vám může pomoci udržet dotazy přehledné a předvídatelné.

Tento rozhodovací strom vám pomůže vybrat správný příkaz pro váš operační systém a předejde chybám syntaxe, když potřebujete rychlý převod.

Výše uvedený blokový diagram jasně ukazuje zásadní syntaktický rozdíl příkazu date na Linuxu (-d @...) a macOS (-r ...) – častou past, do které padají vývojáři pracující v různých prostředích.

Chcete-li svůj kód ochránit, vždy implementujte kontroly, které ověřují délku příchozího časového razítka. Jednoduchá funkce, která kontroluje 10místnou (sekundy) nebo 13místnou (milisekundy) hodnotu, může tyto chyby odhalit dříve, než zanesou do logiky vaší aplikace zmatek.

Nejčastější otázky o Unixových časových razítkách

Jakmile se s Unixovými časovými razítky seznámíte, skoro vždy se vynoří několik praktických otázek. Viděl jsem, jak přivádějí do úzkých vývojáře všech úrovní, takže si objasněme ty nejčastější, se kterými se při své každodenní práci setkáte.

Proč tolik API používá časová razítka místo řetězců ve formátu ISO 8601?

Důvod je čistě v efektivitě. Unixové časové razítko je pouhé jedno číslo, což ho činí neuvěřitelně kompaktním ve srovnání s řetězcem jako '2023-10-27T10:00:00Z'. Tato menší velikost znamená méně dat k přenosu, což šetří šířku pásma a může urychlit odpovědi API.

Jsou také zcela nezávislé na programovacím jazyce. Není zde žádná nejednoznačnost, žádné záludnosti při parsování a žádné starosti s regionálním formátem. Pro stroj je práce s čísly vždy rychlejší než parsování řetězců, takže jakékoli výpočty data – jako výpočet času mezi dvěma událostmi – jsou výpočetně méně náročné. Pro vysoce výkonné systémy je tato jednoduchost obrovskou výhodou.

Jaký je správný způsob práce s časovými pásmy?

Tohle je ta nejzásadnější otázka. Zde je zlaté pravidlo: Unixové časové razítko je vždy, vždy v UTC. Nemá v sobě zabudovaný žádný koncept časového pásma. Je to pouze hrubý počet sekund od epochy.

Časová pásma jsou důležitá pouze tehdy, když chcete toto razítko zobrazit člověku.

Má rada? Na backendu se pro všechno držte UTC. Ukládejte je do databáze jako UTC razítka, předávejte je přes API v UTC a veškerou logiku na serveru provádějte v UTC. Jediný čas, kdy byste je měli převést do místního časového pásma, je na frontendu, těsně před jejich zobrazením uživateli. Tato jediná praxe vás ušetří celého vesmíru chyb souvisejících s časovými pásmy a letním časem.

Měl bych se stále obávat problému roku 2038?

U většiny nových projektů pravděpodobně ne. „Problém roku 2038" je pozůstatkem starších systémů, které k uložení časového razítka používaly 32bitové celé číslo se znaménkem. Jakmile se toto číslo příliš zvětší, překlopí se na zápornou hodnotu a posune data zpět do roku 1901.

Naštěstí téměř všechny moderní systémy – od operačních systémů po databáze – již dávno přešly na 64bitová celá čísla. To efektivně odsouvá tento problém tak daleko do budoucnosti (vlastně o miliardy let), že pro nás již není praktickým problémem.

Pokud však spravujete starší systém nebo pracujete s vestavěným hardwarem (jako jsou IoT zařízení), rozhodně byste si toho měli být vědomi. Vždy znát, na jaké architektuře stavíte.

Jak mohu rychle převést časové razítko v Excelu nebo Google Tabulkách?

Pro toto nemusíte svá data vybírat do samostatného převaděče Unixových časových razítek. Vystačíte si s jednoduchým vzorcem. Předpokládejme, že vaše časové razítko je v buňce A1:

• Pro časová razítka v sekundách (10 číslic): =A1 / 86400 + DATE(1970,1,1)
• Pro časová razítka v milisekundách (13 číslic): =A1 / 86400000 + DATE(1970,1,1)

Jednoduše vložte tento vzorec a poté formátujte buňku jako „Datum" nebo „Datum a čas". Je to záchrana, když rychle analyzujete exporty dat a nechcete narušit svůj pracovní tok.

---

Unavuje vás neustále přepínání mezi editorem, příkazovým řádkem a tuctem záložek prohlížeče kvůli jednoduchým úkolům? Sada ShiftShift Extensions integruje do vašeho prohlížeče výkonný převaděč Unixových časových razítek, formatovač JSON, zkrášlovač SQL a další. Vše, co potřebujete, je na dosah stisku klávesy.

Stáhněte si ShiftShift Extensions a zjednodušte si pracovní postup ještě dnes na https://shiftshift.app