Mno ja nevim. Posledne byl problem v tom ze v jadre byla nejaka chyba co zpusobovala zamrznuti. Pokud bude prestupna minuta, a vkladana jednou za 50 let, tak vyrobci klicoveho softwaru budou kaslat na nejake problemy za 50 let a nebudou pri tvorbe brat na prestupne minuty ohled.
Ted si kazdy uvedomuje ze prestupne sekundy muzou nastat, tak se na to jakztakz ohled bere.
Treba Google to interne dela, 24 hodin predem zacne postupne upravovat cas: https://developers.google.com/time/smear
To uz je daleko za "ani nahodou". Rozkalibrovat si hodiny a ztratit platnost kalibraku, ktery firmu stal ~50 000, to by asi reditel neschvalil...
Coz je mimochodem hadam duvod, proc malokdo pristoupil na to googli rozmazavani prestupne sekundy do celeho dne. Je to dobre pro bezne pocitace, ale kazi to standardy frekvence a to je neprijatelne pro prumysl a metrologii.
7. 11. 2023, 10:53 editováno autorem komentáře
Jojo, přesně tak... rádiem řízené hodiny (nechci tady zbytečně dráždit propagací konkrétní značky, která mě živí) podle všeho jedou především stabilní frekvenci, ostatně čas různých GNSS systémů je monotónní a na UTC se přepočítává offsetem (odečtením celého čísla sekund).
Zkusil jsem si svého času postavit z diskrétních součástek VCXO = krystalový oscilátor laditelný v malém rozsahu napětím. Implementováno pomocí varikapů zvolených tak, aby ve středu regulačního rozsahu měl krystal přesně jmenovitou kapacitní zátěž (v souladu s datasheetem). Dokázal jsem ho tuším kapacitně popotáhnout snad o +/- 100 ppm, než došlo k nějakému rozpadu oscilace. Komerčně vyráběné VC-OCXO mají interval přeladitelnosti mnohem menší - a nevím o tom, že by nějaký výrobce dolaďoval přestupnou sekundu "ujetím frekvence" v bloku rádiového přijímače času. Jak již zmíněno v tomto i dalších komentářích, "družicový čas" to nepotřebuje a firmware přijímačů se taky nemusí ohlížet na POSIX. Ten vstoupí do hry až kdesi na úrovni Linuxového ABI pro user space. (Někde jinde tady v diskusi jsem psal, že linuxový kernel prostě zopakuje vloženou sekundu, na frekvenci běhu své softwarové časové základny kvůli tomu nesahá.)
Na volnoběh, nebo taky při závěsu lokálního oscilátoru servosmyčkou na družice, měla by hrana 1PPS na výstupu přijímače odpovídat vždy přesně pevnému počtu tiků lokálního oscilátoru (v mé realitě má lokální oscilátor 10 MHz). Odchylka 1PPS od UTC je integrálem odchylky frekvence podle času. Nedávná praktická zkušenost mě donutila k zamyšlení, jak správně doladit odchylku 1PPS po nějaké době volnoběhu lokálního oscilátoru (při výpadku upstream referenční frekvence). Srovnat frekvenci fázovým závěsem lze relativně rychle - ale co s nakumulovanou chybou fáze? Překmitnout frekvencí naschvál na opačnou stranu a plynule fázi "doklouzat zpátky"? Inu můj výrobce odchylku fáze nad určitou minimální hranicí dolaďuje jedině skokem = jednorázovým posunem 1PPS oproti ideálnímu dělícímu poměru. Problematika má všelijaké zábavné varianty scénářů a netriviální zákoutí, především pokud "lokální časová ústředna" volí mezi více upstream referencemi různého druhu...