Vlákno názorů k článku Jak jsem lovil přestupnou sekundu od JA - Myslim, ze autor se uz dalsi prestupne sekundy...

Myslim, ze autor se uz dalsi prestupne sekundy nedocka, protoze vetsina predstavitelu z ISO se pry (nutno dodat, ze zcela logicky!) vyjadrilo proti, protoze to zpusobuje problemy na hloupych systemech ..... nutno dodat, ze prakticky vyhradne unixovych.
Je vcelku smesne, ze takovy redhat se musel aktualizovat, aby nahodou .... pritom unixovy timestamp nic jako prestupne sekundy nezna ..... ale treba stupidni python zna dokonce dvojitou prestupnou sekundu (ktera nikdy nebyla, ani nebude) ..... proste je videt, jak nekteri lidi hledaji problemy tam kde nejsou ..... pritom treba vsechny systemy a vsechny interni procesy a aplikace od microsoftu nic takoveho neznaji .... proste se (zcela logicky) tvari, ze zadna prestupna vterina neni, system ji proste nezna! Cili ji ignoruje a pri dalsim NTP requestu se proste upravi systemove hodiny .... jak genialni:o)
Kdezto zaslepena stupidita unixovych vyvojaru k idiotskemu perfekcionalismu (spis by se asi hodilo jine slovo) vedla k obrovskym problemum a pritom stacilo k problemu pristoupit inteligentne (jak to treba udelal microsoft) ......
Ale uplne nejvic me pobavil gugl (na tomhle pripadu je krasne videt, ze se nikdy nemel gugl poustet do programovani radobyoperacnich systemu, proste na to nema mozkovny), kdyz pry den predem posouval cas kazdou chvili o milisekundu:o) To proste blbemu nevysvetlis:o)

Opravdu by me uprimne zajimalo, kterou "chytrou hlavu" napadlo implementovat prestupnou vterinu do IT sveta ... hodiny realneho casu OS se inkrementuji porad, univerzalni (dokonce i unixovy) cas je porad stejny .... akorat fyzicky(!) pribyla jedna vterina. Prave kvuli casovym posunum se zavedl UTC, ktery neresi posuny letniho a zimniho casu nebo casove zony .... taky existujou prestupne roky ...... to vsechno se da pochopit a racionalne vysvetlit .... FYZICKA prestupna vterina je uz obhajitelna opravdu hodne tezko, ale budiz ..... ale to, ze si nekdo da tu praci a uplne nesmyslne horkojehlovou implementaci zanese zcela nelogicky proti rozumu problem do operacnich systemu, to mi opravdu hlava nebere ...... nenapada me (a vlastne nikoho) jaka mela polovicata implementace prestupne vteriny v unixu smysl (krom Y2K, aby se par firem napakovalo, pak ANO), proste neexisuje zadna aplikace, kde by to melo smysl ...... sak taky kvuli unixu/linuxu chcou v ISO a NASA do budoucna prestupne vteriny uplne zrusit, respektive pry hodlaji "tajne" upravit cas jenom na hlavnich NTP a GPS a fuck off .... protoze kdyz to daji vedet takhle dopredu, zacnou do toho unixovi neznalci rypat a jsou pak problemy .... takhle si proste jenom unixovy server v naplanovany cas upravi zcela regulerne vnitrni hodiny a do te doby se bude tvarit, ze se o vterinu predbiha ..... big whoop, koho to zajima? NIKOHO!:o) Kdyz to nezverejni, tak nikdo ani nezjisti, ze se nejaka vterina pridala ..... mozna po par pridani zacne par majitelu super drahych hodinek s cesiovym strojkem remcat, ze se jim predchazeji, LOL:o)

Vy trole.

Ad dojde k obdobnému skoku v náhodný okamžik - nedojde k němu vůbec. Když Windows detekují malý rozdíl mezi lokálním a sítovým časem, provedou změnu rychlosti lokálních hodin tak, aby se bez časového skoku dostaly do shody se síťovým časem. Jen pokud je změna výrazně větší, dojde ke změně času skokem. Na doménovém serveru a stand-alone klientech se by default skokově synchronizují změny větší než 1 sec, na klientech větší než pět minut.
https://technet.microsoft.com/en-us/library/cc773263(WS.10).aspx

Aplikace ve Windows navíc nespoléhají na to, že lokální čas monotónně roste. Používají funkce QueryPerforman­ceCounter() a GetTickCount64(). Výjimkou mohou být aplikace portované z Unixů, případně psané nemehly :)

Jestli se skokem opravuje chyba větší než jedna sekunda, tak po přestupné sekundě to bude v průměru platit alespoň pro polovinů klientů, ne? Nějaká část je napřed o víc jak sekundu, nějaká (menší) část je pozadu o víc jak sekundu a zbytek (pro který se neudělá oprava skokem) je někde mezi tím.

V tom článku co odkazujete se píše, že ten NTP klient neumí držet přesnost hodin lépe jak na pár sekund, tak je to asi stejně jedno. Snažit se řešit nějak rozumně přestupnou vteřinu u hodin s takovou přesností by dávalo asi stejný smysl jako posunovat náramkové hodinky.

Jinak referenční NTP implementace (ntp.org) na Windows řeší přestupnou vteřinu docela pěkně, hodiny se zpomalí na polovinu po dobu dvou sekund.