Google „rozmaže“ přestupnou sekundu 31.12.2016 do 20 hodin

Pouceni: nepouzivejte NTP servery googlu. Protoze ukazovat 20 hodin nespravny cas zcela zamerne je hovadina bez ohledu na ucel.
Zajimalo by me, ktere vsechny systemy s tim maji problem. Ukazuje to na naprostou nekompetentnost a selhani testovani.

Ona je spis naprosta hovadina prestupna sekunda. Realne totiz naprosto nikoho nezajima. Nebo tobe snad vadi, ze tvuj server bude mit cas o sekundu za rok posunutej proti astronomicky poloze Zeme vuci Slunci? lol ...

Je to stejna hovadina, jako kdybych rek, ze kazdej 123 !az! 571km ma prestupnej mm.

Zato resit, ze nekdy nekde muze mit minuta sekund 61 je pomerne hodne netrivialni uloha. A muze to rozbijet nehoraznou spoustu veci.

To je zajímavé, přestupný den nevadí, ale sekunda ano.
A reálně to prý nikoho nezajímá. Přestupný den taky nikoho nezajímal a ejhle, v kalendářích máme rozdíl mnoha dní.

Ano, přestupný den nevadí, protože je jasně dán pravidly a lze s ním v programech počítat na miliardy let dopředu. Narozdíl od moderní kokotiny zvané přestupná sekunda, kterou si nějaký pošuk vyhlásí půl roku dopředu a myslí si, že se kvůli němu všichni poserou.

Ta prestupni sekunda tu mela byt uz davno pred 10 lety ale porad se odkladala protoze pry software neni pripravenej, GPS skolabuje a pod. Ted uz konecne bude.

Dovedu si predstavit, ze kdysi davno nekdo proti prestupnejm dnum protestoval uplne stejne :-D

1. Jedna otazka je, zda je prestupna sekunda hovadina, nebo spravna vec. Na tohle uplne uzavrenej nazor nemam.

2. Jina otazka je, zda je debil ten, kdo si z nekolika existujicich norem presneho casu vybere cas koordinovany a pak jej umyslne mrvi. Proc? Vzdyt mame cas TT, tam jsou vsechny sekundy stejne dlouhe, jako u UTC a odvozene ze stejneho mezinarodniho souboru hodin. A nikdo nic nevklada. Misto informace o tom, ze je to v UTC v casove zone Bangladese proste reknu, ze je to v case TT a nasrat. Vsechny moje stoje pojedou v TT a kdo bude chtit interoperabilitu s UTC, prepocita si to.

Ti, kdo povazuji prestupnou za blbost, pojedou v TT. Kdo si mysli, ze prestupnou chce, treba proto, aby byl kompatibilni se zakonem danym casem ve spouste zemi, tak si to prepocita. Tabulku vsech vlozenych/ubranych prestupnych stejne musi mit, jinak by v UTC fungovat nemohl. Vyhodou je, ze kdo bude mit komplet "UTC-free" system, muze stale pouzivat normalizovany a kodifikovany cas TT, o ktery se staraji tytez instituce, jako o UTC.

proste reknu, ze je to v case TT a nasrat. Vsechny moje stoje pojedou v TT a kdo bude chtit interoperabilitu s UTC, prepocita si to.

Mě se hrozně líbí, jak tyhle akademici vždycky vymyslej jako "řešení" jimi způsobených problémů nějakou úplně nepoužitelnou píčovinu

Fakt, jo? Picovina TT je tu s nami (nepatrne) dele, nez atomovy hodiny samotny. Rekl bych, ze tedy nemuze byt povazovana za reseni "problemu", ktery byl zpusoben (tedy zaveden) az pozdeji.

Dale, domnivam se, ze nespokojeni uzivatele casu UTC v kontextu zpravicky a diskuse by uvitali, kdyby jeli v prostem case skladajicim se z 60sekundovych minut a nikdo by sekundy ani neubiral, ani nevkladal. Proto vykrikuji svuj nazor, ze tito lide by tak tedy meli cinit -- a pouzivat cas TT (resp. TAI, berte to jako synonyma). A ne misto toho vymyslet vlastni (dementni) casovou stupnici, ktera nema v nicem oporu, a jeste predstirat, ze jde o UTC. To je prece pracny a navic pitomy (muze to zpusobit problemy).

Je spousta reprezentaci, ktere s prestupnou sekundou zadny problem nemaji, treba nejstarsi unixova klasika, pocet sekund od 1.1.1970. Kdo ma aspon zakladni pgm mysleni, tak si pro svoje ucely vybere nekterou z techto reprezentaci a muze mu bejt uplne jedno, jesli kral Lol Phi na ostrove Banuatu svym ediktem zavede jarni a podzimni cas. A nebo (temer) ekvivalentne IERS vyhlasi, ze bude prestupna sekunda. To prece ovlivni jen prepocet vnitrniho casu (TT/TAI, resp. sekundy od 1.1.1970) na nejakou mistni, (idiotskymi/ge­nialnimi) zakony danou casovou zonu... UTC, UTC s letnim casem,... atd.

Dovedu si predstavit primitivni SW, kterej nema podporu vubec zadne casove zony a ani prestupnejch sekund. Ten necht jede v TAI a cau. Pak si dovedu predstavit SW, kterej potrebuje export/import casu v nejake zakonem dane casove zone, OK, opruz, pak necht si svuj vnitrni cas (treba TAI, nebo soubor krystalu na desce od okamziku prvniho vycteni OS po zapnuti stroje, plus aktualni NTP/PTP korekce) prevadi na prislusne varianty UTC. (Pokud na ostrove Banuatu se osviceny panovnik rozhodne na UTC nasrat a odvodit svuj cas od TT, ma jiste tu moznost a z hlediska logiky SW to nic nemeni.) Zde ale nevidim jedinej duvod, proc by zpracovani prestupnejch sekund melo vyzadovat jakkoli jine zpracovani v SW, nez zpracovani letnich aj. casu a prislusne historie legislativnich zmen.

Takze jsem presvedcen, ze vsechny SW, ktery prestupny vteriny borej, jsou napsany blbe a -- pozor! -- podelaly by se i pri legislativnich zmenach casovych zon (letnich/zimnich aj.) -- ke kterym dochazi. Sach mat, jdi se vycpat.

> Vsechny moje stoje pojedou v TT a kdo bude chtit interoperabilitu s UTC, prepocita si to.

Tuhle úroveň abstrakce bohužel systémy, které používám a ladím, neumí.

To přece vůbec nevadí, že to neumí,akademici si zanadávají na ten zlý Google, jak nemá pochopení pro jejich 59/61sekundové minuty a kazí jim jejich úsilí o hyperpřesná měření dilatace času a rotace Země tím, že je prostě ignoruje.

Pak je to spatne. Takovy system se pravdepodobne ekvivalentne podela, az Putin/EU/PSP zrusi letni cas, nebo zmeni den, kdy nastava a konci. Coz se deje.

Tvrdim, ze neni reseni, kdyz 20 hodin jedu v lzivem case a tvrdim, ze je to UTC. Tvrdim tez, ze je lepsi jet v lzivem case a netvrdit, ze je to UTC. Nejlepsi je samozrejme jet interne v nejakem TT (TAI) a la sekundy od narozeni Krista UNIXa Forda Pana, a prepocty na (slozite a hlavne *menlive*) legani casy vystrnadit na same okraje (rozhrani) vypocetniho systemu. Tot vse.

Kdo ma SW a souvisejici prostredky tak dojebany, ze vyse zminenou abstrakci neumoznuji, pak je stejne v haji, nebot mu nebude fungovat:

- synchro podle NTP
- urcovani a porovnavani legalniho casu (pripadne bude fungovat jen nekdy, ale s bugama)
- synchro podle GPS, DCF
- vypocet, zda se dany okamzik nachazi v pracovnim dni, statnim svatku, v danem roce,...

Naproti tomu mohou i bez vazeb na vnejsi svet hezky fungovat veci, jako: natahni budik na n sekund m nanosekund a vzbud proces; urci casovou posloupnost a intervaly vnejsich udalosti; vytvor v budoucnu porovnatelne casove razitko; atd.

Viz poslední odstavec zde. Zejména mají na práci lepší věci, než řešit akademické pošukoviny jakýchsi samozvaných časoměřičů.

Prolitnul jsem to a zda se mi, ze prispevek hlasa zhruba: bojime se, ze jsme v hromadach existujiciho SW my resp. jini autori mozna neco zprasili tim zpusobem, ze by to pri korektnim pouziti prestupnejch sekund delalo potize. Potud rozumim a chapu motivaci.

Nejak mi ale neni jasnej ten dusevni pochod, proc misto prajednoduche prace se "sekundami od 1.1.1970" a tedy rekneme TAI*), se rozhodli pro adaptivni mrveni UTC. Nejak tam nenalezam moznost vlozit komentar, tak jim moje moudra kritika asi zustane utajena, je mi to jedno, na Googlich sluzbach prilis zaviset nehodlam.

*) Mejme milion pocitacu/OS/da­tabazi, ktere jsou napsany vsemozne dementne tak, ze jim muze UTC (s prestupnyma) skodit. Dodavam, co pisu jinde, ze dost pravdepodobne by tymz systemum skodila i v nesikovnou chvili implementovana legislativni zmena letniho casu, napr. Necht se vsechny tyto debilni systemy synchronizuji na vnitrni NTP Googlu. (Coz tak je, od toho se odviji ta zprava -- tyto Gugli NTPd delaji ten bordel, aby shitozni softy byly braneny pred zlym vnejsim svetem prestupnych sekund.) Pro zajisteni konzistence bych nastavil casovou zonu TAI+0h. Ty uplne nejdementnejsi SW, co koncept casovych zon neznaji, budou tuto skutecnost v pohode ignorovat (lokalni cas OS). Kdo bude do casovejch zon vrtat, tomu aspon tato informace zabrani se nejakym omylem srovnat se skutecnym UTC. Tomu je stejne treba zabranit i v aktualni implementaci, behem polameho preladovani sekundy je nepripustne, aby nekdo z blbecku v ohrade srovnaval svuj falesny Google-UTC s vnejsim skutecnym UTC. No a timpadem jedine stroje, ktere budou muset umet znat rozdil mezi TAI a vnejsi casomirou (cizi NTP, GPS cas aj.), jsou ty NTPd servery. Ktere to i v soucasne implementaci delaji.

Zaver? Nevidim duvod, proc by melo jakekoli roztahovani sekund a praseni UTC casu nejak pomoci. Totez lze jednoduseji, cisteji a s mensimi riziky implementovat jako receno vyse.

Kristova noho. V praxi bylo zjištěno, že to způsobuje fatální problémy (viz odkazy). To, že akademik nepochopí, že v praxi je třeba dát přednost tomu, abychom těmto problémům předešli bez ohledu na to, jestli to uráží jeho akademické a vědecké cítění, přičemž s omezenými zdroji (čas/lidská síla, peníze) musím nakládat efektivně, to bohužel není nic nového.

Ja ti nevim, co mas, hochu, v hlave za virus. Ja vyse, snad pro mene retardovane i srozumitelne, popisuji, jak tehoz vysledku -- zabezpeceni blbe napsanejch SW -- dosahnout, aniz bych si jako pitomouckej trulant z Googlu hral na nakou vlastni a nekompatibilni variantu "UTC s chvilema natahovanym casem". Proste at jedou vnitrne v TAI a maji naprostej klid. O co jde? Pokud potrebuji srovnat cas sami se sebou (v ramci Google molochu), neni problem. Pokud potrebuji nekde blit cas, odpovidajici zakonu nejakeho statu, pak -- prekvapeni -- to stejne nejde udelat bez aktualnich databazi. Cili, bud si zavolaji funkci (RPC...), ktera prepocet z TAI provede. Nebo v pripade nejdebilnejsich kusu SW se na to proste vyserou a vypisou TAI, cili lez. Coz je extremni a blbej pripad -- zhruba stejne blbej, jako kdyz v dobe gumovejch sekund blijou svoje Google-UTC a tvrdej (lzive, a to s chybou az 1s) ze jde o UTC.

Mozna by mohli misto kokotin vyuzit sveho vlivu a vice popularizovat (existujici, kodifikovany a s existujicimi SW nastroji) cas TAI, kdyz se jim nelibej prestupny.

Hosu, mame tady asi tak 100 miliard zarizeni a z nich asi tak tisicovka umi s touhle picovinou fungovat. Vsechny ostatni na to serou, a nikomu to nevadi. Divny co?

A abych nezapomel sem vazne zvedav, jak budes tu prestupnou sekundu implementovat do mych - velice presnych - mechanickych hodinek. Nemuzu totiz zit s pomyslenim, ze jdou o celou sekundu neprepresne ... ou shit ... musim je rozmlatit, behem myho zivota se rozejdou mozna i o 10 sekund ... katastrofa ...

Se na chvíli proleť rychlostí světla, pánové akademici ti přece daj včas půl roku předem vědět kdy bude ta správná sekunda, tak nechápu, na co si stěžuješ... :-D

Jako casomeric rikam: jsou to dementi.

Zcela nezavisle na tom, zda je prestupna sekunda dobrej napad, nebo neni. Ja myslim, ze cas UTC je praktickej a pulrocni perioda oznamovani budoucich +-1s mi prijde pro velke mnozstvi aplikaci v pohode. Naproti tomu, pokud nekomu UTC opravdu vadi nebo z nejakeho duvodu nemuze bulletiny IERS zapracovat, pak muze jet v case TT (nebo treba GPS case). Bude-li tato informace o nekoordinovane (ve smyslu vkladani prestupnych) casove zone pritomna spolu s casovym razitkem, bude vzdy mozna okamzita nebo zpetna konverze na UTC a nemuze to delat problem.

Google to (zas jednou) podelal. Neni to poprve, co nakaslali na standardy (zbytecne).

nemuze to delat problem.

Tak určitě...

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1020285
https://bugzilla.redhat.com/show_bug.cgi?id=836803
http://www-01.ibm.com/support/docview.wss?uid=swg21602521

Lolku, tobe prestupna sekunda rozhodila vedeni nebo zpusobila poruchu osobnosti, ze vubec nereagujes na to, co pisu? Tak to zkus znovu, jo:

pokud nekomu UTC opravdu vadi nebo z nejakeho duvodu nemuze bulletiny IERS zapracovat, pak muze jet v case TT [..] Bude-li [..] informace o [..] casove zone [mysleno TT] pritomna spolu s casovym razitkem, bude vzdy mozna okamzita nebo zpetna konverze na UTC a nemuze to delat problem.

Jinymi slovy: je pro vas z duvodu omezeni HW/SW (napriklad nemoznost zapracovavat pulrocni bulletiny z duvodu omezene datove komunikace, nebo nutnosti nastavovat cas udalosti v predstihu vetsim, nez je pulrok, coz se muze legitimne stat -- byt takovych aplikaci asi bude malo) nepouzitelnej cas UTC? Pak jedte v TT. At klidne vsechny servery, certifikacni autority a vsichni podobni podporuji casovou zonu TT, ja budu jedine rad.

Urcite to neni vetsi potiz, nez podporovat vsechny zony letnich/zimnich casu, ktere se legislativne meni podobne casto, jako dochazi k vkladani sekund. Taky, kdyz poslanci odhlasuji, plati jinej prepocet letniho casu -- a je nutno to nekam zanest (stejne jako prestupne sekundy). Jedina "zona" (casova stupnice), ktera je vuci tomuto vsemu imunni, je prave TT.

At klidne vsechny servery, certifikacni autority a vsichni podobni podporuji casovou zonu TT, ja budu jedine rad.

Viz.

Vidim, ze se na nicem nemuzete dohodnout

A znáš ten jak je v hladomorně je mrtvý matematik, zavřená konzerva, stoh popsaných papírů, z nichž každý začíná: "Nechť je konzerva otevřena."? :-D

Konecne podnetnej navrh. Pohonem bude stavajici jadernej arzenal vojenskejch velmoci?

"Problém by mohl nastat, jestli použijete ntp servery Google a zároveň jiné „nerozmazané“ ntp "

Zadnej problem nastat nemuze, to ze se jednotlivy NTP rozchazej je normalni. Lock se dela na ten, kterej ma aktualne nejmensi rozptyl, naopak pomerne kurevskej problem muze nastat, pokud nekdo system, kerej zije v tisicilenym presvedceni ze minuta ma 60s, pripoji na ntp, kterej mu nareportuje tu sedesatou prvni.

Ale nic skakat nebude ... ntp v ramci nejakych mezi dela presne to co google - zpomaluje a zrychluje hodiny. Pokud sou napred, tak je zpomali, kdyz sou pozadu, tak je zrychli, ale v zadnym pripade neprepina cas tam a zpet, neprekvapive prave proto, ze by to defakto uplne vsechno rozbilo, kdezto ruzne dlouha sekunda nikomu nevadi.

Kdyz je rozdil moc velkej, tak to ntp vyhodnoti jako chybu a sync proste nebude.

Jiste, protoze to vymejslej stejny kokoti ... kdyz nasi predchudci rekli, ze den ma 24hodin, hodina 60 minut a ta 60 sekund, tak at si tihle kreteni upravi delku te sekundy, jedinej problem je totiz prave v tom, ze nejakej uberkokot vymysli nejakou zcela jinou definici sekundy ... a ted se divi, ze to nesedi na astronomickej pohyb, tak vymejsli jeste vetsi kokotiny.

A ze to defakto znamena, ze ta sekunda neni kazdej den stejne dlouha? No a? Kdyz totiz zahrnu dalsi fyzikalni jevy, tak ten metr je taky kazdou pikosekundu jinak dlouhej - podle zcela libovolny definice.

Den ma 86400 sekud ... exaktne a zcela presne. Libovolnej den.

Dylka metru se meni uplne stejne jako dylka sekundy, nevsim sem si, ze by nase planeta sedela naprdeli uprostred vesmiru, a jelikoz se tim vesmirem pohybujem pomerne slusnym kalupem, a ten kalup se celkem slusne meni, tak se meni i dylka toho metru ... divny co?

Pokud sis toho jeste nevsim, tak cas a prostor spolu pomerne slusne souvisej.

Ad Den ma 86400 sekud ... exaktne a zcela presne - a tradičně úplně špatně. Sekunda je definovaná takhle: the duration of 9 192 631 770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the cesium 133 atom. Tj. sekunda je vždy stejně dlouhý časový úsek. Ono těžko mít jako základní jednotku času něco co má každou chvíli jiné trvání.

A pokud má sekunda vždycky přesně stejné trvání, a zároveň se rotace Země mění, tak je nutné upravit délku dne v sekundách, aby se čas nerozjížděl.

Upravit délku sekundy tak aby se měnila je dost velký problém, protože jak jsem psal, těžko mít základní jednotku které se mění velikost. Od sekundy se totiž odvozuje řada dalších věcí, celkem zjevné jsou třeba frekvence. Méně zjevné je to že třeba vzdálenost zcela běžně měříme pomocí doby letu světla, a protože světlo je zatraceně rychlé, tak se změnou délky sekundy by se měnily i naměřené vzdálenosti.

Pokud jde o počítače, tak tam sekunda ve většině aplikací nehraje až takovou roli, a naopak sekunda navíc zjevně dokáže způsobit Unixovým systémům veliké problémy. Proto se dá použít zjednodušení, kde se prostě na nějakou dobu upraví délka sekundy tak aby se nemusela přestupná sekunda přidávat/odebírat. Možná to není úplně ortodoxní řešení, ale je to praktické a funkční. Mimochodem Windows tohle řešení používají odjakživa.

Ad se meni i dylka toho metru - jak konkrétně se mění? Mám na mysli jakým konkrétním způsobem ten "kalup" mění délku metru, a o kolik konkrétně?

Aha, změníme délku sekundy. To je dobrý nápad. Budeme pak přecejchovávat tachometry? A co jednotky? Necháme Watt jako kg*m^2*s^−3, nebo tam přidáme nějaký korekční koeficient, abychom neměli "nový Watt" a "starý Watt"? A budeme tu délku sekundy měnit každý rok, podle toho, jak se Země vyspí? Nebo se nějaká komise pokusí spočítat "správnou délku sekundy" a pak to pošleme na boha, aby se podle toho zařídil a laskavě nám držel stálou oběžnou dráhu?

Jedna sekunda a kolik je kolem toho rozruchu :)

Je smesne jak it kre*eni jsou schopni zpochybnovat validitu astronomickeho casu, protoze se to zrovna nehodi je jejuch hloupe navrzene systemy. Nastesti je milion plus jedna podstatnejsich branzi...ale chapu ze na to nemate mentalne a vas vztah k casu konci u ntp :-)

Aaaa, další dotčený akademik...

Může bejt, že to ten jejich slepičí mozeček nepochopí, ale čas je fyzikální veličina a fyzika patří mezi exaktní vědy. Co znamená slovo "exaktní" již přenechám na tobě, aby sis to zjistil.

Jojo, náhodné šoupání se sekundami je exaktní jak stehno z vánočního kapra.

svet tu neni proto aby to mel nejaky retardovany informatik jednoduchy...nor­malne nejsem sprosty ale tyhle nazory tady aspon je videt co za hovadka v tyhle branzi jsou. se divim ze jsme prekrocili rok 2000 a radsi jsme radikalne nezkratili definici sekundy, abychom 2000 aspon o 20 let odsunuli

Jenze cas jako fyzikalni velicina je daleko lepe vyjadren pomoci fyzikalniho casoveho modelu TT (https://en.wikipedia.org/wiki/Terrestrial_Time), ktery je v praxi realizovan atomovymi hodinami jako TAI.

Ferren mel zrejme pod 'astronomickym casem'[*] na mysli UT (https://en.wikipedia.org/wiki/Universal_Time), coz vlastne ale z fyzikalniho hlediska vubec nemeri plynuti casu, ale otacky Zeme, a to v jednotkach, ktere vlastne vubec nejsou jednotkami casu (i kdyz se jim snazi podobat).

A pak tu mame hybrid UTC, ktery micha vice nekompatibilnich konceptu dohromady (mereni rotace zeme podle UT, ale pomoci jednotek casu, tedy SI sekund) a problemy s tim spojene hackuje prestupnymi sekundami.

Lide nezpochybnuji validitu UT obecne, ale jeho relevanci pro civilni cas (tedy mimo specificke aplikace, ktere potrebuji presnou informaci o rotaci zeme). Zruseni prestupne sekundy se diskutuje v ITU. Pokud je zadouci zachovat aspon obecnou vazbu civilniho casu na rotaci zeme, tak je mozne nahradit prestupnou sekundu prestupnou hodinou realizovanou pomoci posunu casovych pasem.

[*] To oznaceni samo o sobe je vagni, protoze jak TT tak UT jsou astronomicke standardy a v astronomii jsou potreba oba - TT pro urceni kdy k danemu jevu dojde a UT k urceni toho kde na obloze ho hledat.

Zruseni prestupne sekundy se diskutuje v ITU.

A anžto vytváření nejrůznějších nových pracovních skupin je doslova požehnáním pro nepoužitelné akademiky, kteří tak mohou předstírat činnost a rajzovat po světě za cizí peníze, tak se ještě dlouho diskutovat bude.

Ano, s timto nazorem souhlasim. Myslim, ze kriticka cast vypocetnich systemu by mela bezet ve vnitrnim monotonnim case ("tiky od zapnuti", i kdyz kazdy, kdo mrknul na zalostnou situaci s existujicim HW v dnecnich multiprocesorovych, uspavacich a spotrebne-zmrvenych systemech vi, ze ani tahle velicina neni tak jednoducha a nekdy je vubec i nemozne ji spolehlive [!] naemulovat z dostupnych citacu). Toto a nic jineho musi byt CLOCK_MONOTONIC.

Dale pak, kdo nema na to se obsirat s definici legalnich casu pro dane staty (a nepotrebuje to), je podle me jedinou rozumnou volbou TT/TAI. Ten narozdil od vnitrniho casu (CLOCK_MONOTONIC) ma tu vlastnost, ze je porovnatelnej s celym svetem a metrologicke ustavy se o nej staraji jednotne s UTC a hranice sekund jsou stejne.

Kdo potrebuje z jakehokoli duvodu legalni cas, musi implementovat knihovny, obsahujici kalendar legislativnich zmen a prestupnych sekund. Z cehoz plyne, ze pro integritu vnitrniho zpracovani je vyrazne jednodussi jet v TAI a tyhle korekce na UTC a letni/velikonocni provadet mimo jadro vypocetniho systemu. Kdo to tak nema, zadela si na podobny problem, jako prepocitavat CLOCK_MONOTONIC zpetne z korigovaneho casu. Jinymi slovy: rovnak na vohejbak.

Myslim si, ze vsechny 3 casy, CLOCK_MONOTONIC (integrita jednoho OS, hlavni vnitrni cas kernelu), TAI (integrita napric ruznymi OS) a UTC (srovnani s legalnim casem) maji sve misto. Ale lopaticky by si mely umet vybrat, v kterem z nich danou operaci provedou.

To souvisí s debilizací IT posledních 20 let. Dnes se do toho hrne spousta lidí s nedostatečným IQ a důsledky vidíme.

Ano.

Konkretne, mrknemez se na ten, zdejsim apologetou Google-casove stupnice zminovanej, bug v jadre linuxu: zavadeni prestupnych sekund do subsystemu timekeeping zpusobilo, ze CLOCK_MONOTONIC nebyl monotonni... proc asi... protoze timekeeping v Linuxu je nepekne zmastenej a jsou tam kusy NTP (ktery tam, prekvapeni, vubec nemusej bejt). A predevsim, jede se tam ten horsi styl, kdy se neustale neco reguluje, misto, aby vse vnitrne jelo v monotonnim case a vsechny ostatni "obcansky" a NTP casy z toho byly pocitany korekci. Cely NTP a veskera infrastruktura prestupnejch sekund v userspacu (vc. gettimeofday, coz uz nastesti dnes funguje a lze to) a mimo vliv na vnitrni chod jadra. Inu, nejak se tam naakumulovala v kodu ta "ryba v nas".

Mimochodem, posledni okamzik me snahy s tim neco delat byl loni v rijnu, kdy jsem svoji predstavu o reseni (kudos Pavlu Pisovi za pomoc s vhledem do kernelu) nutil pro osobni schuzce Poul-Henning Kampovi, ale nenarazil jsem na pochopeni. Co uz, Linux Foundation plati(la) jemu a ne me, tak necht je to jeste nejaky cas nebo deset let rozmrveny, mezitim se budu zabejvat casomirou, ktera zivi me.

nenarazil jsem na pochopeni.

Fňuk, akademiky nemá nikdo rád :-DDD

Fňuk, akademiky nemá nikdo rád :-DDD

A to souvisi zhruba jak s dle meho nepriznivym vysledkem rozhovoru dvou ne-akademiku? Byl nas hovor s PHK snad ovlivnen temnou aurou zamecku v Sevres u Parize, znameho coby sidlo zla a metrologii stizenych akademiku? Nemyslim.

PHK zavolali z Linux Foundation a nacpali mu prachy, jelikoz plati za jednoho z mala lidi v pruniku mnozin "OS" a "casomira" a on zacal svuj ntimed (uz jsem na vyvoj rok nekoukal). Kouknul jsem na to a jelikoz jsem mel zrovna cestu do zednarske loze na dulezite zasedani o tom, jak jeste vice zkomplikovat vypocet, kolik je prave ted hodin (tru story, bro), tak jsem s PHK hodil rec a snazil jsem se ho tlacit do vyse zmineneho stylu: drzet vse v monotonnim a korekce vystrnadit do co nejvyssich (ve smyslu hierarchie) a nejokrajovejsich (ve smyslu rozhrani) casti OS/SW. Nesouhlasil, coz je podle me blbe; myslim, ze prijde den, kdy to zas po PHK nekdo bude muset predelat.

Bohuzel nemam v soucasne dobe kdy na charitu a popravde cas v OS je zatim pro vsechny moje systemy irelevantni, tak jsem se do psani patche nepustil, i kdyz jednou za cas si na to s Pavlem Pisou vzpomeneme a kdo vi, treba dojde k tomu, ze budu i cas v OS nutne potrebovat (a nebo nekdo jinej, kdo na to da prachy) a pak se misto kecu dame do dila na linux/timekeeping. V nejblizsim pulroce to nehrozi, za okny zuri kapitalismus a musim tezit $.

Je jasný, že zrušit přestupnou sekundu je blbost. Je to potřeba nějakým způsobem korigovat, aby časem nevycházelo slunce třeba v 11.

Ale proč zrovna sekunda? To jako musí nutně vycházet slunce na vteřinu stejně?

Nebylo by lepší místo přidávání 1s každých ~ 1,5 roku přidávat 1 minutu jednou za ~ 90 let?

Další možností by byla hodina, to už bysme se dostali někam k periodě ~ 5400 let. Nicméně to mi nepřijde jako ideální. Hodina už je docela znát a navíc je to takové to odsouvání problému dalším generacím. Myslím, že < minutu by v rozmezí 90 let nikdo nepostřehl a nemuselo by se to každou chvíli řešit.