Vlákno názorů k článku Kde se berou IP adresy, postkvantová kryptografie a přestupná sekunda, LinuxDays 2025 od K> - "Už přesně víme, jak dlouhá je sekunda "...

Čo myslíte? Práve systémové funkcie môžu vrátiť aj leap seconds. Som zvedavý koľko SW počíta s tým že sekundy majú rozsah 0-60.

Ano, a proč by s tím měl software nějak speciálně pracovat? Pokud to jen zobrazí nebo uloží, není s tím problém. Pokud potřebuje spočítat rozdíl nebo porovnávat dvě časové značky a použije knihovní funkce, není s tím problém. Problém nastane, pokud si někdo usmyslí, že si to naimplementuje sám, ale o problematice práce s datem a časem nic neví. Jenže taková implementace často pohoří i na letním čase nebo přestupném roku.

No ze napriklad ked meriate cas medzi dvomi bodmi a medzi 12:30:34 a 12:31:34 to trvalo 61 sekund.
Ze napriklad ani nepocitate pri zobrazeni s tym ze na prvej pozicii v sekundach moze byt 6, ... veeeela chyb sa da urobit ak proste nepocitate s tym ze minuta moze mat aj 61 sekund.

No ze napriklad ked meriate cas medzi dvomi bodmi a medzi 12:30:34 a 12:31:34 to trvalo 61 sekund.
To řeší použití knihovní funkce.

Ze napriklad ani nepocitate pri zobrazeni s tym ze na prvej pozicii v sekundach moze byt 6
Při zobrazení málokdy musíte počítat s konkrétní číslicí.

veeeela chyb sa da urobit ak proste nepocitate s tym ze minuta moze mat aj 61 sekund.
Ty chyby se udělají hlavně tehdy, když si to někdo řeší sám, aniž by si problematiku nastudoval.

Disky jsou poslány. Nechcete už tuhle fejkovou komedii ukončit?

Dobře, ale proč bych měl u každého měření ještě měřit délku sekundy? Kdybych to musel dělat, tak si pořídím přesné externí hodiny a na linuxu čas rovnou zruším. Měnit zavedený standard je hloupost, kdybych měl atomové hodiny, tak sekunda je definovaná jako přesný počet (9 192 631 770) přeskoků hladiny v Cesiu. Tomu cesiu fakt nevysvětlíte, že teďka má skákat na jiné hladině, protože někdo nemá rád číslo 61.

Ale zavedeny standard vzdy bol ze minuta ma 60 sekund. To ze ich ma viac zaviedli az 'nedavno'. Dovtedy sme si stacili s driftujucim casom ktory aj tak na pocitaci mame.

pokud toto potrebuji, tak proste pracuji s reprezentaci casu v sekundach... a nemusi me trapit vnejsi reprezentace a.k.a H:M:S... prechodne sekundy jsou jen korektiv te citelnejsi reprezentace, ale k zadnemu realnemu prodlouzeni v definici minuty nedoslo

Ale zavedeny standard vzdy bol ze minuta ma 60 sekund.

Tohle není zcela přesné. Čas byl definován podle pohybu Země kolem Slunce a rotace Země a nějak se zavedly zlomkové jednotky (H, m, s). Jenže to se ještě nevědělo, že se rotace Země zpomaluje, takže vlastně nic z toho nevychází a mění se v čase. Po tomto zjištění se doplňují nebo ubírají další sekundy právě proto, aby to sedělo s astronomickým pozorováním.

Ale zavedeny standard vzdy bol ze minuta ma 60 sekund.

A taky, že den má 24 hodin... Počkat...? Posledních 46 let mi to 2x za rok nějak nesedí. A taky, že rok má 365 dní. To taky posledních 2069 let jednou za 4 roky nesedí... A to, že to nesedí, taky není posledních 441 let 3x za 400 let pravda... Vesmír si zkrátka jede svoje a na lidské škatulky a zavedené standardy z vysoka - víte co...

Mimochodem, ve středověku u nás byly driftující hodiny, půl roku dopředu a půl roku dozadu - tak, aby každý den mohlo Slunce zapadnout přesně ve 24 hodin, jak se sluší a patří. Ovšem v klášterech ještě mniši navíc požadovali, aby také odbitím 12. hodiny noční každý den Slunce i vyšlo a 12. hodiny denní zapadlo, takže denní a noční hodiny jim tam každý den driftovaly proti sobě.

"Pavel Tavoda Ale zavedeny standard vzdy bol ze minuta ma 60 sekund."

Doopravdy je to celkem irelevantni. Dnes je sekunda definovana mnohem lepe nez vy kdy budete merit. Pokud si zacnete sekundu vyrazne prodluzovat, pak jiz nemerite v sekundach, ale v nejakych vasich jinych jednotkach, a musite provadet konverzi na sekundy, ktere uznava cely zbytek sveta, vcetne USA, a to uz je co rict.

Takze prodluzovani sekundy znamena opustit to co delaji vsichni ostatni a zavadet novou jednotku. A to je presne to co naprosto absolutne nechcete, protoze se s tim poji milion dalsich problemu, a problemy znamenaji chyby, a to vse znamena ekonomicke ztraty. Nejde jen o pocitace, ale i to k cemu jsou pocitace pouzivany - automatizace, vyroba, mereni... Jasne, nejaky excel a pocitani polozek ve skladu to neovlivni, ale svet neni jen o tomhle.

Přestupné sekundy máme od roku 1972. Za tu dobu jsme v IT měli spoustu generací různých technologií, stejně tak většina lidí, kteří tu diskutují, nejspíš dobu bez přestupných sekund nezažila, nebo byli v plenkách. Přestupné sekundy nejsou žádná novinka.

Na tom, že máme na různých zařízeních s dostatečnou přesností (výrazně méně než jedna sekunda) synchronní čas je založena spousta technologií. Bez toho by se musely synchronizovat jiným způsobem a bylo by to výrazně dražší nebo pomalejší.

Mě ani tak nevadí, že to někdo v diskusi neví, od toho je to web pro širokou veřejnost. Ale vadí mi, že i v IT se lidé brání knihovnám (třeba timezone, o tom bych mohl napsat knihu, co kdo všechno a jak počítal) a místo timedate.Add nebo Sub to počítají jak na základní škole a pro jistotu do db to ukládají bez TZ.

Tak me napada, je nekde nejaka validace takovych knihoven? Kazdy jazyk ma vlastni, nekdy i vice nez jednu, tak by bylo fajn vedet jak spravne funguji driv nez je clovek pouzije. Problem je ze takovou validaci ta knihovna sebou netaha a nechlubi se ji na prvni strance githubu, a nejspis vetsine lidi ani neprijde na mysl neco takoveho hledat.

Tak minimálně se dají porovnávat mezi sebou. Ono na TZ je nejdůležitější tam mít správné termíny zavedení, zrušení a posunů těch pásem. Ty výpočty zase tak složité nejsou. Pokud to nějaká vláda změní a oznámí to o roky později, tak je problém, ale tohle se dneska nestává.

No, ono když jistý diktátor v KLDR oznámil změnu časového pásma v roce 2018 jen týden dopředu, také to nebylo úplně ideální.

To je asi posledni problem, ktery svet okolo realne trapil. Jako akademicky problem dobry, ale realny impact je zanedbatelny. Mimoto updatovat tzdata je otazkou chvile stejne jako zajistit deploy bezpecnostnich zaplat. TL;DR neexistujici problem :)

Tak me napada, je nekde nejaka validace takovych knihoven?
To je dobrá připomínka. Já o takovém testu nevím.

Přestupná sekunda a půlhodinová nebo čtvrthodinová časová pásma jsou ještě poměrně jednoduchá. Horší to začne být, když potřebujete používat různé kalendáře, případně pokud potřebujete řešit datum i hodně do minulosti a musíte řešit, kdy kde platil jaký kalendář.

Pro vývojáře softwaru je ale myslím stejně největší problém to, který typ času (kterou „jednotku“) mají kdy použít. Protože to za ně žádná knihovna nevyřeší, to je byznysová záležitost. Tj. kdy mají používat lokální/místní datum a/nebo čas (calendar date, wall-clock time), kdy používat geografické časové zóny, kdy časové zóny určené posunem vůči UTC. A teda knihovna jim v tom moc nepomůže, když třeba oba dva typy s časovou zónou spojí do jednoho typu (významně se dívám na nový JavaScriptový Temporal).

Proste si priznejme ze problematice zcela nerozumite ( ja take ne ). Proto pouziji specializovanou knihovnu a udaje z ni interpretuji volne - nehonim je pres omezenejsi datove typy.
Vlastni implementaci prace s casem udela jen naprosto nevzdelany prilis sebevedomy associate apprentice junior z pocitacoveho krouzku programovani neznaly problematiky.

Tady je takovy "kratsi" seznam z praxe na co musite pamatovat:
https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca
Knihovna za vas pamatuje i na edge cases ktere v tomto seznamu nejsou.

V praxi s cim jsem se posledni leta setkal:
- prestupy letni/zimni cas kazde pasmo jine a jindy
- zona nema zarovnanou 1h
- prestupna sekunda zbori dodavateli aplikaci
- americky format data nespravne implementuji i americani - viz. ta ohyzdnost formatu data v jazyce go
- progros ma 20 let stare definice zon a nepouziva standartni knihovny - zmena zony nastala driv nez release cyklus aplikace
- aplikace predpoklada ze cas na stroji je v lokalni zone v miste kde se vyviji

Ale vysvětlíte to tomu cesiu celkem snadno, stačí vedle něj navozit hromadu šutráků, a dtau = dt * sqrt(1- 2Gm/(c^2*r)) kde r je poloměr té hromady, m je její hmotnost, G je Newtonova konstanta, c je rychlost světla.

Jak to logisticky zvládnout je už jiná otázka

15. 10. 2025, 21:56 editováno autorem komentáře

Ale jo. Ok, dám na své atomovky závaží :-D

Alebo PTP.!?

Pricemz zrovna pocitacovy hodiny jsou hodne tragickej zdroj casu.

S NTPd napojeném na státní etalon času není a v naší práci je to dokonce dané vyhláškou (zpracování veřejných zakázek). Je to auditované a ještě navíc to kontrolujeme proti GPS.

V normálním operačním systému se ale čas neurčuje podle hodin počítače, nýbrž si ho udržuje operační systém jinými prostředky – a např. si to ještě upřesňuje dle NTP a počítá si, jaká je odchylka jeho měření času od NTP a provádí průběžně korekci.

Hodiny v počítači slouží jenom k tomu, aby čas tak nějak plus mínus autobus běžel, i když je počítač vypnutý, a po startu počítač tušil, ve kterém je století (teda spíš den a pokud možno i hodinu), než se to srovná podle NTP. protože pro NTP obvykle potřebujete DNS, pro to zase potřebujete rozumně přesný čas kvůli DNSSEC – aneb nastavit přesně hodiny je obtížné, pokud vedle nemáte hodiny, které ukazují alespoň rámcově něco, co se blíží aktuálnímu času.

Filip Jirsák: "V normálním operačním systému se ale čas neurčuje podle hodin počítače, nýbrž si ho udržuje operační systém jinými prostředky " - opravdu? A co jsou ty jine prostredky?

Ja bych spis rekl, ze na motherboardu je oscilator, od ktereho se odvozuje cas, a sem tam se provede korekce pomoci NTP. Ale NTP nemuze bezet kazdou mikro/nano sekundu. Musi byt nejaky lokalni hardwarovy oscilator, od ktereho se ten cas odvozuje, a ten oscilator muze leda tak prochazet korekcema.

Ano, bezny oscilator v pocitaci ma houby presnost, takze druhy den uz je videt jak odjel. Bohuzel, od te doby co existuje vsudypritomny internet a NTP se obvykle zacaly pouzivat fakt nekvalitni oscilatory ktere neudrzi rozumny cas ani par dni, protoze prece se to muze porad synchronizovat, zeano :(

Pokud jako "hodiny počítače" označíme modul RTC - neboli takovou tu věc, co potřebuje baterii CR2032, tak ta se skutečně používá jen pro udržení přibližného času, když je počítač vypnutý. Existuje spousta počítačů, které tento modul vůbec nemají (například Raspberry Pi až do verze 4 nebo drtivá většina domácích routerů s výjimkou produktů Turris), případně které mají modul nepoužitelný kvůli nefunkční baterii. Přesto takové počítače jsou schopné ukazovat čas.

Systémový čas se obvykle posouvá na základě přerušení, která pravidelně posílá řadič přerušení. Je tedy odvozený z frekvence systémového oscilátoru, který rozhodně na většině počítačů extrémně přesný není.

Ano, za hodiny počítače považuju RTC.

Nicméně když na tom počítači běží NTP, změří si, o kolik a kam ten systémový oscilátor ujíždí, a skutečný čas pak měří jako čas vypočtený z toho systémového oscilátoru plus korekce. Výsledek má docela slušnou přesnost, rozhodně to není, že by za sekundu vznikla sekundová chyba. NTP už se pak používá jenom k doladění přesného času a úpravám té korekce.

Aby jirsak nezacal plkat o vecech, o kterych nema paru ze?

NTP, jen "sem tam" lehce zpomali/zrychli ten citac, kterej pocita cas (=zmeni to nastaveni delicky, ale to ty nemuzes vedet ...). Coz je neco, co je pro jakykoli mereni tak maximalne ubermegalol. Je to mnohem horsi, nez kdyby na tom PC zadny ntp nebezelo.

I mechanicky cibule budou presnejsi. Kdyz nic jinyho budou mit totiz nejakou odchylku, ktera bude alespon konstatni.

Aby jirsak nezacal plkat o vecech, o kterych nema paru ze?
Pokaždé, když napíšete něco takového, znamená to, že bude následovat váš text plný nesmyslů.

NTP, jen "sem tam" lehce zpomali/zrychli ten citac, kterej pocita cas (=zmeni to nastaveni delicky, ale to ty nemuzes vedet ...). Coz je neco, co je pro jakykoli mereni tak maximalne ubermegalol. Je to mnohem horsi, nez kdyby na tom PC zadny ntp nebezelo.
Nikoli. NTP je protokol pro synchronizaci času přes internet, a také se tak označuje (např. v této diskusi) služba, která tento protokol využívá pro synchronizaci systémového času (= času operačního systému).

Ta služba čas od času (obvykle v řádu minut) zjišťuje rozdíl mezi aktuálním systémovým časem a časem udávaným několika NTP servery, na které je daná služba napojená. Zjištěný rozdíl se pak snaží korigovat. Když není rozdíl moc velký, krátkodobě zrychlí nebo zpomalí systémový čas, aby se srovnal se zjištěným správným časem. Když je rozdíl větší, změní čas skokově. Když je ještě větší, jenom to zaloguje chybu. Je to obvykle konfigurovatelné, takže si třeba můžete stanovit, že při startu služby (po startu počítače) se čas srovná vždy, i kdyby byl posunutý o několik let.

Vedle toho se služba NTP snaží udržet správný běh systémového času, aby ty nutné korekce, které se provádějí jednou za několik minut, byly minimální. Dělá to tak, že sleduje nějakou dobu historie, jak se systémový běh času liší od správného času, a podle toho zrychlí nebo zpomalí běh systémového času.

NTP se považuje za dostatečně přesný zdroj času ve spoustě systémů, kde je to potřeba pro synchronizaci třeba napříč lokalitami. Takže NTP rozhodně není k ničemu, jak se snažíte tvrdit. Jako zdroj (občanského) času je to tedy použitelné velice dobře. Pro měření krátkých časových intervalů to vhodné není, ale pro to to nikdy nebylo určeno.

Pane Jirsáku, omlouvám se, ale to je naprostý nesmysl. To platí možná posledních deset let. A to ještě jenom částečně. Jak samozřejmě i vy dobře víte.

Mně to takhle v linuxu fungovalo už před 25 lety.

Oprávněn určitě je, root.cz nevydává žádné povolenky nebo něco.

Ale myslím si že rozumný člověk si nejprv tu diskuzi aspoň zběžně projde. Ovšem jestli měl jen potřebu vyjádřit svůj názor i když už ten názor tady vyjádřen byl, pak si stále myslím že platí jedna ze dvou variant co jsem nastínil výše.

Ano, jsem si jist tím co píšu.

Ono si stačí přečíst ostatní jeho příspěvky a je jasné, že platí obě dvě varianty najednou…