Vlákno názorů k článku Přestupná sekunda nás nezaskočí, věří si velcí hráči českého internetu od . . - rádiově řízené hodinky si při nejbližší synchronizaci načtou...
-
. . (neregistrovaný)
rádiově řízené hodinky si při nejbližší synchronizaci načtou aktuální čas a budou zase běžet přesně.
Tohle se týká jen zařízení, které s tím umí pracovat a řeší přestupné sekundy a i na těchto systémech aplikace dostane logický čas 59:59:59 a "60" se jim tam nikdy neobjeví.
Jvm pro javu nebo i erlang si řeší vnitřní hodiny sami a může s tím být problém, protože dojde k velkému skoku a můžou se nějaká data poškodit nebo dokonce dojít k nekonečné smyčce, jak k tomu došlo před několika lety.
V přestupnout sekundou mají třeba obrovský problém velké databáze nebo hodně zatěžované systémy a v tomhle prostředí je nejlepší změnu rozložit do třeba předchozích 16 hodin a každou minutu protáhnout o jednu ms
-
M. (neregistrovaný)
Hodinky, pokud jsou to moderní na linuxu, tak na nich pravděpodobně proběhne 2x po sobě sekudna 23:59:59 UTC a pojede se dál. Pokud jsou teda řízeny přes NTP/DCF/..., kde se dozví o přestupné sekudně v předstihu nebo mají aktualizovaný soubor tzdata s uvedenou přestupnou sekudnou.
Zkrátka doběhne čas normálně npřes 23:59:59 na 1:00:00.<něco málo> a skokem se skočí o sekundu zpět na 23:59:59.<něco málo> a sekunda proběhne ještě jednou a pak se jede dál.... Problémy plynou z toho, že některá čekání tak mohou být o sekundu delší, což vše nemusí vydržet, pokud aplikace používá časovač odvozený z reálného času a ne monotonní. -
Rádiově řízené hodinky dokonce z DCF vědí o přestupné sekundě předem, takže se teoreticky nemusí synchronizovat dodatečně, ale mohou zobrazit rovnou správný čas 1:59:60. Samozřejmě za předpokladu, že se u nich někdo s implementací přestupné sekundy namáhal - což by mělo význam asi jen u nějaké značky, která by si zakládala na tom, že má vyřešené vše do posledního detailu.
