Názory k článku
Google „rozmaže“ přestupnou sekundu 31.12.2016 do 20 hodin
-
j (neregistrovaný)
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.
-
Lol Phirae (neregistrovaný)
Ale nic nebylo přesunuto... https://www.ietf.org/timezones/data/leap-seconds.list
-
Filip JirsákStříbrný podporovatelVzhledem k tomu, že ta přestupná sekunda bude dvacátá sedmá, už by nikoho překvapovat neměla. Mimochodem, od roku 1972 vychází průměrně 1,6 přestupné sekundy za 4 roky, zatímco 1 přestupný rok za 4 roky. Takže přestupná sekunda je „normálnější“ než 29. únor.
-
robotron (neregistrovaný)
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.
-
robotron (neregistrovaný)
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/genialnimi) 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.
-
robotron (neregistrovaný)
Proc bych ti to prevadel na UTC, ty chces prece pouzivat cas bez prestupnejch sekund, cili TAI. Na UTC (a prislusnou casovou zonu) necht to prevede nekdo, kdo ji pouziva. A pokud ji pouziva, musi znat prislusnou korekci, tedy aktualni zneni sbirky zakonu a .txt bulletinu IERS. Pokud nezna zneni zakona a stav IERS, pak mu je udaj v UTC naprosto ku hovnu a mene skody si zpusobi, pokud ode me prijme casove razitko v TAI.
-
Lol Phirae (neregistrovaný)
To UTC (a příslušnou časovou zónu) používají v praktickém životě všichni. TT nepoužívá krom akademických pošuků nikdo. Ale chápu, že akademika netrápí to, zda 1230768000 převede na 2008-12-31T23:59:60.0 nebo na 2009-01-01T00:00:00.0, přičemž ovšem praktické následky (například nevratné zmeškání lhůty) mohou být zcela fatální.
-
robotron (neregistrovaný)
Ja to zkusim jeste jednou, jo, jestli ti to treba nahodou nedocvakne.
"Zmeskat lhutu" je urcite vec, ktera nema oporu v plynuti casu vsehomira jako takoveho, ale je navazana na nejakou pravni situaci, ktera se opira o legalni cas urciteho statu, ktery je -- ve vetsine civilizovanych zemi -- odvozen od UTC. OK, chapu zadani? Napriklad: je nutne poslat hash/aktivovat neco nejpozdeji na konci roku 2008.
Necht jedu v tom systemu, ze vnitrne mam SW napsanej na pytel a bojim se a vsechno uvnitr je v TAI a ulozim pocet s od 1.1.1970. Pokud potrebuji toto prevest na dny a roky dle zakona dane zeme, stejne potrebuju znat historii legislativnich zmen a aktualne platnych letnich/kdovijakych casu. Takze pokud to hodlam mit na salamu a nepouzit spravnou fci prevodu z TAI na legalni cas, pak mam problem bez ohledu na existenci prestupnych s. To samy se treba tyka vypoctu poctu pracovnich hodin v danem casovem intervalu. Bez aktualnich (a menicich se) informaci ze zakona to neni mozne.
Pokud ovsem na druhou stranu nepotrebuji v dane aplikaci resit zakon dane zeme a staci mi vnitrni lhuty -- coz treba na spoustu veci muze dostacovat, napr. vyprseni platnosti nejakejch aktivacnich kodu, sifrovacich klicu, hashu,..., tak muzu naprosto smele ignorovat veskery UTC sekundy a vrtochy parlamentu a jet v tech sekundach. Dokonce i smluvne lze toto bez problemu specifikovat, na nasem uzemi min. od r. 1811, tim, ze proste lhutu uvedu v sekundach.
-
robotron (neregistrovaný)
Tak mi rekni, pro jakou zemi. A nebo pouzij https://cr.yp.to/libtai.html
-
Lol Phirae (neregistrovaný)
Já myslím, že zadání bylo dostatečně pochopitelné, akorát to řešení, lišící se rokem, je zcela neuspokojivé, vinou podobných akademiků a jejich kundovin s přestupnou sekundou. Tak myslím, že by bylo vhodné, kdybyste si vedli svůj vlastní čas pro pošuky, zbytek populace vaše onanie s rotací Země a gravitační dilatací času tak nějak obtěžuje.
-
robotron (neregistrovaný)
A hele, vypada to, ze konecne v tvejch hamotinach je nejakej naznak myslenky. Tak myslím, že by bylo vhodné, kdybyste si vedli svůj vlastní čas pro pošuky, zbytek populace vaše onanie s rotací Země a gravitační dilatací času tak nějak obtěžuje.
Co se tu snazim sdelit, by sice melo byt soucasti cca maturitniho vzdelani, ale ocividne to nekteri (jako asi ty) nechapou. Posuci velmi korektne davaji k dispozici hned nekolik casu s ruznymi vlastnostmi. Napr. UT1 je zhruba receno vzajemny uhel Zeme-Slunce. TT (~TAI) je zase cas, ktery jakakoli nebeska telesa ignoruje a jede si svoje cesiove sekundy pekne jednu za druhou, kazda minuta jich ma 60. Na to je pak napojenej Gregorianskej nebo Julianskej kalendar, co se pouziva v Asii a jinde, to nevim a je mi to momentalne celkem jedno, kolik SW jede mimo Gregorianskej a Julianskej netusim. Dalsi z casu je UTC.
Z nejakyho duvodu, trebas i blbyho, se vetsina "populace", resp. tech grazlu, kteri jim v ramci politiky danych zemi vladnou, priklonila k UTC jakozto legalnimu casu. Mozna je to zlo, ktere poslancum naseptali casomerici v zajmu zeslozitit to a zajistit si praci na sto let dopredu na naprave hruz, zpusobenych prestupnou sekundou. Nevim. Rikam jen, ze naprosto ekvivalentni (ba, rekl bych, horsi) zmeny se deji co psana historie saha. Vzpomenme: 1. Juliansky kalendar; 2. Gregoriansky kalendar a s tim souvisejici bordel napric svetem, kdy kazda zeme presla jindy (a to i o par set let); 3. letni/zimni cas, ktery od dob B.Franklina dodnes je predmetem neustalejch zmen, i jen v okruhu par tisic km a za poslednich 10 let tech zmen bylo nekolik -- jak ruseni/zavadeni, tak zmena dat, kdy probiha; 4. prechod na pasmovy cas (ten mozna nadelal skod nejmene, ale prinejmensim mel vliv na jizdni rady a nahle zvysil naroky na infrastrukturu, konkretne telegraf v roli "NTP"); 5. prestupne sekundy.
Zajimavy pro tebe muze bejt, ze posuci si obvykle dobrovolne praci nekomplikujou, takze je velmi caste jet v TAI popr. Julianskem (!) kalendari.
Jak ale pisu vyse, pro prevod nejakou fyzikalni metodou (krystal, GPS, NTP) mereneho casu na legalni datum necini prestupna sekunda kvalitativni rozdil oproti ostatnim legislativnim parametrum. Procez, pro prevod v minulosti je nutne mit databazi. Prevod neomezene daleko do budoucna neni mozny. U prestupne sekundy je aspon jistota na nejblizsi >=pulrok. (Tahle jistota u nekterych legislativnich zmen ani nemusi byt zarucena. I [ale nejen] proto je moudre vnitrne jet v necem nezavislem, jako je TT/TAI.)
-
robotron (neregistrovaný)
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.
-
robotron (neregistrovaný)
P.S.: ja treba spoustu cinnosti na svem pocitaci provadim v casove zone "Praha/Berlin/Pariz/..". Ta je uplne strasna a ma mnohem desivejsi zaseky, nez nejake prestupne sekundy. Ma dokonce prestupne dny a co hur, i prestupne hodiny. Navic ten okamzik, kdy se vklada/ubira hodina, plati teprve od r. 1996, coz je dokonce mladsi, nez byl muj Slackware 3.0.0. (A aby to bylo zabavnejsi, ten okamzik v ramci roku dokonce pluje podle tydenniho rytmu, ale to je nastesti celkem predvidatelna fluktuace.) Ve srovnani s prestupnou sekundou je ovsem hrozive, ze pro casovy interval v podzimni kladne prestupne hodine ani nelze pouzit lexikograficke razeni casu podle hh:mm. I z tohoto plyne, ze pouzivat jako vnitrni reprasentaci cokoli nez neco jako TAI/TT sekundy od okamziku O je blbost.
-
Lol Phirae (neregistrovaný)
Takovy system se pravdepodobne ekvivalentne podela, az Putin/EU/PSP zrusi letni cas
Systému, který jede s hodinami v UTC, je Putinův a jakýkoliv jiný letní čas u prdele. Pokud někdo používá systém od soudruhů z Redmondu, je to jeho problém.
Tvrdim, ze neni reseni, kdyz 20 hodin jedu v lzivem case a tvrdim, ze je to UTC.
Ano jistě, zato čas, který tvrdí, že minuta do půlnoci má 59/61 sekund, ten lživý není, neb se na tom akademici usnesli a celá zeměkoule se musí točit podle nich.
urcovani a porovnavani legalniho casu (pripadne bude fungovat jen nekdy, ale s bugama)
A už jsi vyřešil ten bug s převodem přestupné sekundy na UTC, který jste způsobili?
-
robotron (neregistrovaný)
Je to elementarni, nemily Trollku:
a) Systému, který jede s hodinami v UTC, je Putinův a jakýkoliv jiný letní čas u prdele. => Pak takovy system nedokaze urcit napr., kolik hodin a jake datum je v dane zemi. Procez tvrdim, ze by ekvivalentne mohl jet v TT/TAI a asi by se nic nerozbilo.
b) system potrebuje znat legalni cas => pak mu Putinův a jakýkoliv jiný letní čas u prdele byt nemuze.
c) system nepotrebuje legalni cas, ale potrebuje interoperabilitu s UTC => pak musi volat Jenda.oser() a udrzovat db prestupnejch s. Ciste proto, ze samo UTC ma ty sekundy v definici.
-
robotron (neregistrovaný)
Nejak ti tam upadla jednicka, ale je zjevne, ze narazis na http://www.madore.org/~david/computers/unix-leap-seconds.html#the-reality
Zde ty POSIXove sekundy nejsou TAI, pri prevodu do tehle epochy se ztraci informace. Maximalni chyba je 1s, takze je to zhruba stejne debilni, jako to nereseni od Googlu ;-) Oboji je spatne.
-
robotron (neregistrovaný)
Vypadam snad jako nekdo, kdo pouziti vyse propiraneho POSIXu doporucuje? Vzdyt ja prece pisu, ze mnohem bezpecnejsi je jet v klasickejch unixovejch sekundach od 1.1.1970 a la TT/TAI. Pravda, je to v rozporu s POSIXem, nebot ten vyslovne vyzaduje vyse zmineny nemonotonni cas a nejednoznacnost casoveho razitka. Ze je to mozna dost blba norma? Nehadam se, nebyla by to prvni zhovadilost v POSIXu.
-
Lol Phirae (neregistrovaný)
Takže to jsme moc nepokročili, že, soudruzi...
Jinak norma v tomto ohledu zcela v pořádku, narozdíl od počínání rozhádaných akademiků, na jejichž krávoviny s přestupnou sekundu krom již zmíněného Googlu sere také Amazon, Akamai, nebo třeba asijské finanční trhy (všechni ostatní po dobu akademického šoupání se sekundami raději zavírají krám).
-
nejsem schopen určit, jestli se něco stalo v jednom roce nebo až v tom dalším.
Udalosti, u kterych nejsi schopen urcit, v kterem roce se staly, byla uz cela rada. Treba v kterem roce vyhynuli dinosauri? Asi nejlepsi bude pozadat svetovou populaci, aby v kritickych okamzicich, jako v tvem prikladu, nedelali nic, co by bylo potreba zaznamenat do databaze. Muzou se treba zastavit a pul minuty se dloubat v nose.
-
robotron (neregistrovaný)
Nepodělá, docela mi to s tím funguje.
Muzes mi rict, jak principialne odlisne zpracujes, ze od r. 1996 je v CR letni cas jindy, nez v roce predchozim? Je to prece obdobna operace, jako kdyz IERS vyhlasi prestupnou sekundu. (Pravda, ten letni/zimni je o mnoho slozitejsi a bori lexikograficky poradi. Ale i to je v GNU implementovano.)
K poznamce nize: pises "ve vsech app krome jedne to tak bylo". Muzes dat nejaky konkretni priklady? Ocekavam neco, co se pri 40s podela, pri 1s nepodela a zaroven to neumi pracovat v prostredi s prestupnyma sekundama. Mozna bude tvuj vycet inspirativni a pochopim mysleni nekterych zbloudilcu, ale nevim nevim.
-
Karel (neregistrovaný)
Jen bych upozornil, že historii letního času musíte držet jako tabulku. A budoucnost v ČR znáte jen do roku 2021. To možná vypadá jako daleká budoucnost, ale to jen proto, že nařízení vlády je z letošního října. A je jen do roku 2021. O dalších letech pak vyjde nové nařízení, někdy v tom roce 2021.
Snažím se říci, že pokud letos v září váš program evidoval nějakou událost na přelom března a dubna roku 2017, tak to z podstaty věci dělal špatně. Pracoval jen na základě toho, že si autor vyvěštil z křišťálové koule, že vláda se rozhodne schválit stávající metodiku, že letní začíná poslední neděli v březnu a končí poslední neděli v říjnu. Vláda se naštěstí rozhodla potvrdit stávající metodiku určení dne, kdy se čas mění, takže váš program to nakonec počítal dobře. Ale za pět let to tak být nemusí, klidně to mohou udělat jinak.
V USA je to ještě větší legrace, protože tam si to každý stát dělá po svém. Nepřechází v jeden den a některé nepřechází vůbec. Navíc mají některé tendenci to rok od roku měnit. Že vám vaše věštba o českém čase vyšla je sice fajn a pravděpodobné, ale jakmile to chcete řešit na globální úrovni, tak je to na Chocholouška. To se pak řeší tabulkami a prostým konstatováním, že to budoucnost vzdálenější než 3 měsíce může ukazovat špatně. Což je například u plánovacího kalendáře pro konferenční hovory docela mazec.
-
Filip JirsákStříbrný podporovatel
Karel: To ovšem popisujete situaci, kdy si čas evidujete v jiné časové zóně, než ve které jej zadal uživatel. Což je čistě vaše volba, nikdo vás k tomu nenutí. Když si dnes něco zaevidujete na 12:00:00 30. září 2030 v časové zóně Evropa/Praha, máte to zaevidované naprosto přesně a žádná změna vyhlášky vám to nerozhodí. Jediný „problém“ je v tom, že ten údaj nedokážete stoprocentně spolehlivě převést do jiné časové zóny do té doby, než vyjde ta aktualizovaná vyhláška. Ale i to lze s docela velkou jistotou odhadnout. Problém nedělá to střídání času, problém v tom může udělat akorát vláda, která změnu pravidel schválí na poslední chvíli.
-
Lol Phirae (neregistrovaný)
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čů.
-
robotron (neregistrovaný)
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/databazi, 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.
-
Lol Phirae (neregistrovaný)
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.
-
robotron (neregistrovaný)
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.
-
Lol Phirae (neregistrovaný)
Aha. Takže omezené zdroje, kvůli kterým je neefektivní/nemožné procházet veškerý používaný kód a zjišťovat problémy s přestupnou sekundou, využijeme tak, že přejdeme na zpětně naprosto nekompatibilní neimplementovanou věc. Tím se skutečně ušetří spousta času a bude to úžasně zpětně kompatibilní a interoperabilní se zbytkem světa.
Dej si ránu do škeble, akademiku.
-
robotron (neregistrovaný)
Zpetne nekompatibilni a nepodporovanou? To si blbý, alebo čo? Sekundy od 1.1.1970 jsou snad podporovane uplne vsemi soudobymi vypocetnimi systemy. Nemluvim teda o dernostitkovejch COBOLskejch hruzach kdovi kde na IBM/3xx, co muzou jet v BCD case. Ale to, predpokladam, se Googlu netyka. I kdyby jo, takovejm systemum beztak zadny ochcany Google-NTPd nepomuze.
Ranu do skeble uschovanou ve vhodnem kondenzatoru si schovam pro tebe, az dorazis na nakej Root-troll sraz. Pce co tu jedes za nesmysly, to je fakt moc.
-
robotron (neregistrovaný)
V TAI nejede zbytek světa
Ano.
a půl minuty už je moc velký rozdíl.
Zatimco 1s je maly rozdil? Tohle ti nak nezeru. Podle me dost zalezi na aplikaci. Proc 30s je NOK a 1s OK? Ne, ne, tohle je podle me zhoubne mysleni a zaklad toho, na co poukazuju. I u takovy hovadiny jako fotbalove sazky behem zapasu se hraje na ~ms. Nemluvime jeste o tydytech jako jsou financnici. (Vedatory a geodety jsme pro blaho veci eliminovali predem.)
A bohužel automatický přepočet často rozumně dělat nejde, nebo by to znamenalo moc velký oser.
Ano, oser. Zakonem definovany. Bud ten zakon nepotrebuju a tudiz v tom case nemusim jet, nebo mi nevadi 30s rozdil, nebo --- musim oser podstoupit. Porad lepsi ho podstoupit na jednom definovanem miste (RPC TAI tz => legalni tz), nez vytvaret novou, nekompatibilni stupnici. Podesate tvrdim, ze bez softwarove shodneho, ba mnohem vetsiho, oseru stejne neurcim ty veci, jako letni cas. Takze kdyz uz se podobne oserozni rutiny museji volat, muzou to vzit se sekundama pri jednom.
-
Jenda (neregistrovaný)
> Zatimco 1s je maly rozdil? Tohle ti nak nezeru. Podle me dost zalezi na aplikaci. Proc 30s je NOK a 1s OK?
Protože pro všechny aplikace (OK, teď už až na jednu) kde jsem to zatím použil to tak bylo. Tečka.
> Bud ten zakon nepotrebuju a tudiz v tom case nemusim jet, nebo mi nevadi 30s rozdil, nebo --- musim oser podstoupit.
Nebo pro mé aplikace vadí 30s rozdíl, ale nevadí 1s rozdíl.
-
robotron (neregistrovaný)
Jeste k V TAI nejede zbytek světa a půl minuty už je moc velký rozdíl. v kontextu Googliho pareseni.
Chapu-li to spravne, tak {Jenda, Lolek} jsou toho nazoru, ze existuji zajimave aplikace, ktere:
- nepotrebuji umet stanovit legalni datum/cas;
- ale potrebuji byt zavesene na UTC;
-- s chybou 1s, ktera nevadi;
-- s driftem 1s/20h, ktery nevadi;
-- zatimco chyba ~40s by uz vadila.Ja osobne mam dojem, ze mnozina takovych aplikaci je mala az prazdna. Vysoce presne aplikace muze snadno rozesrat drift 1s/20h, popr. odchylka 1s (to je mmchd. 3x vic, nez radiem ze Zeme na geostacionarni drahu a zpet). Pomijim-li casomiru a geodezii, kde se hraje na pikosekundy, pak takove obyc veci, jako telekomunikace, synchronizace DVB vysilacu, rizeni prenosove soustavy aj. jsou radove jinde.
Docela by me zajimaly priklady aplikaci, ktere 1s/20h + +-0.5s nerozhodi a +40s-1s uz ano. Zadna me ted nemuze napadnout -- krome tech, ktere zaroven potrebuji i stanoveni roku, dne a hodiny dle zakona. Piste priklady.
-
Karel (neregistrovaný)
Máme dva časy:
Jeden jsou atomové hodiny, které nám přesně říkají, kolik času uteklo (teorii relativity nechme stranou)
Druhý je astronomický čas, který se určuje podle polohy Země vůči slunciTy časy se liší, protože Země je ovlivněna okolními tělesy tak, že se její rychlost a trajektorie mění. Ne o moc, jen o trochu. Ale dost na to, aby se jednou za pár let ta chyba nasčítala na celou sekundu.
A teď přišla ta otázka, který použít. Zatímco ten atomový je krásný, tak ten astronomický je užitečnější. Pokud bychom používali ten atomový, tak by nám dnes slunce vycházelo a zapadlo o několik sekund jinak, než před 50 lety. Teoreticky by se tak za 1000 let mohlo stát, že by v prosinci slunce vycházelo v poledne a zapadlo v půl deváté. Pro astronomický čas navíc mluví fakt, že se používá tisíce let (znali ho už staří číňané), případně se dá říci, že miliony let (den začíná východem slunce).
A konečně ta poslední část, IT. Softwareoví inženýří si museli rozhodnout mezi dvěma zly:
1. použít atomový čas a pak ho přepočítávat na astronomický, podle seznamu korekcí
2. použít astronomický čas a pravidelně ho upravovat podle seznamu korekcíOficiálně si vybrali možnost 2. Ve skutečnosti se jich na to řada prostě vybodla a použili "systémové hodiny".
A má pointa? To "přepočet často rozumně dělat nejde, nebo by to znamenalo moc velký oser" je nevyhnutelné. Buďto to absolvujete při přepočtu atomového na astronomický, nebo to absolvujete jednou za pár let při úpravě času. V obou případech je zadání víceméně stejné. Osobně si myslím, že jednou za pár let oser je lepší, než komplikovat každý převod. Na druhou stranu na to takhle programátoři obvykle dlabou (což oni dlabou i na přestupný rok, jak jsem letos v únoru zjistil). Ale principiálně to prostě absolvovat musíte, ať už se rozhodnete jak chcete.
-
robotron (neregistrovaný)
To jsem rad, ze tu taky nekdo chape podstatu uskali legalniho casu (v.t. https://www.root.cz/zpravicky/google-rozmaze-prestupnou-sekundu-31-12-2016-do-20-hodin/898487/ ), ktera ma mnohem zasadnejsi, mene predvidatelne a co do dopadu vyraznejsi zaseky, nez jsou prestupne sekundy.
Spravne podotknuto, ze cas muzu bud (a) prubezne korigovat a jet v "koordinovanem", nebo (b) jet vnitrne v monotonnim TT/TAI a korekce delat pri "I/O" casovych razitek.
V mnoha podobnych situacich, nejen v otazkach casomiry, vidam inzenyrska reseni, ktera jdou cestou (a). Tj. regulovat misto udrzovat informaci o odchylce. Nerikam, ze je to vzdycky blbe, ale... z me zkusenosti je vetsinou cistsi a nakonec mene problematicke jet spis v (b). Vetsina SW je naprosto spokojena, kdyz muze jet v monotonne rostouci posloupnosti sekund (tj. ne prisne POSIXove, ale rekneme "unix pred uvedomenim si UTC"). Obecny problem pristupu (a) je, ze "regulaci" neco ztracim, pokud si nevedu denik, jak jsem upravy provadel. A pokud si ten denik vedu, jsem na reseni stejne narocnem, nebo narocnejsim, jako (b).
-
j (neregistrovaný)
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 ...
-
robotron (neregistrovaný)
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).
-
FíkZlatý podporovatelno nejlepší pro ty padavé aplikace by bylo, když by to rozmazal ntpd a on to taky umí (slew, parametr -x) a je to omezeno 500ppm, takže v pohodě
http://developers.redhat.com/blog/2015/06/01/five-different-ways-handle-leap-seconds-ntp/
stav, kdy některé servery dávají až o sekundu jiný čas než jiné mi přijde nešťastné
-
robotron (neregistrovaný)
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.
-
Lol Phirae (neregistrovaný)
At klidne vsechny servery, certifikacni autority a vsichni podobni podporuji casovou zonu TT, ja budu jedine rad.
Viz.
-
j (neregistrovaný)
"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.
-
FíkZlatý podporovatel
No to ano, ale ten server s nejmenším rozptylem na který se pověsí, nemusí být 20 hodin ten stejný. Pak to bude skákat. Do toho rozptylu se navíc připočte chyba odhadu času odpovědi a to se může dost měnit.
Tak je potřeba mít ten sw, co se baví s ntp v pořádku. Třeba ntpd se z 61 nesloží a systému to přeloží jedním ze dvou způsobů, podle toho, jak si ho nastavíte. Buď skokově posune čas v zad, nebo to rozmaže.
-
j (neregistrovaný)
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.
-
FíkZlatý podporovatel
defaultní ntpd bez -x udělá skok, viz první graf tu: http://developers.redhat.com/blog/2015/06/01/five-different-ways-handle-leap-seconds-ntp/
-
j (neregistrovaný)
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.
-
FíkZlatý podporovatel
Nějak to pletete, sekunda a metr je pořád stejně dlouhá. Den není stejně dlouhý kvůli nepravidelnosti rotace Země a koriguje se to těmi přestupnými sekundami.
-
j (neregistrovaný)
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.
-
FíkZlatý podporovatel
den teda nemá 86400 sekund: ... However, the duration of one mean solar day is now slightly longer than 24 hours (86400 SI seconds) because the rotation of the Earth has slowed down. ...
https://en.wikipedia.org/wiki/Leap_second
délka metru (definice pomocí sekundy a rychlosti světla) a sekundy (definice pomocí kmitů Cs133) se nemění, co se mění je délka dne a divný to nikomu není
TAI den má přesně 86400 sekund, ten je ale posunutý oproti UTC a bude se nadále posunovat
-
j (neregistrovaný)
Jiste, pokud nejaky kokot redefinuje sekundu. Definici sekundy je, ze to je jedna sedesatian minuty, a minuta je jedna sedesatina hodiny, pricemz den je rozdelen na presne 24 dilku, kterym se rika hodina.
A i pri ty kokotsky definici se dylka metru meni, protoze se pohybujem vesmirem relativistickou rychlosti, coz neprekvapive znamena, ze se meni i dylka ty sekundy podle kokotsky definice.
-
Ondra Satai NekolaZlatý podporovatelI kdyz uz placas, tak se zkus neprezentovat informacemi z prvni tridu zakladky. Ze te pani celka neco naucila neznamena, ze je to cela pravda. Jenom aproximace pravdy, co jsi byl schopen pobrat.
To, co povazujes za definici, uz je redefinovana delka hodiny. Velmi casto byla puvodne definovana jako dvanactina delky dne. Kde den byla "svetla doba" mezi vychodem a zapadem (coz samo o sobe neni zas tak jednoduche rozumne definovat), tudiz neco, co trvalo na ruznych mistech a v ruznych dnech ruzne.
-
j (neregistrovaný)
Cekal sem kdy se tu negramotnej nekola objevi ...
Az mi prineses ukazat RAM velkou 1000B ... tak se muzem bavit o tom, ze kB je 1000B.
Tohle je picovina naprosto stejna.
A sem ty vazne zvedavej, jak budes treba bezci vysvetlovat, ze ten svetovej rekord vazne neprekonal, protoze do tech jeho 2 hodin bylo vlozena prestupna sekunda, takze jeho cas je 2.02:58, coz je o sekundu vic ...
-
Ondra Satai NekolaZlatý podporovatel
Tak jeste jednou - ne, neni to jak si predstavujes. Rikalo ti to tu uz dost lidi. Tva predstava byla norma po pomerne kratkou dobu - pred ni vypadala hodina uplne jinak a pak... to uz tu taky psalo dost lidi. Kdybys psal misto "je definovana" jako "si definuju", tak bys mel vicemene pravdu. Klidne si zavadej nejake alternativni jednotky, jen je, prosim, pojmenuj jinak, nez jak je pojmenovavaji lide, co tomu rozumeji.
Ja nemusim bezcum vysvetlovat vubec nic... to bys mysel ty se svym konceptem casu ze zakladni skoly. V nem je skutecne nektera sekunda jina nez jina... (Navic bezec je od tohohle odstineny, protoze je za vrstvou abstrakce, co obstarava vyrobce stopek. Ktery, pokud nemaji nejakou synchronizaci s okolim, ale trebas jen sleduji kmitani neceho, tenhle problem resit nemusi.)
-
FíkZlatý podporovatel
definice SI sekundy jako 1/86400 platila kolem roku 1940, to jste tedy dost opožděný a zde bych se snad ani nebál použít cizího slova retardovaný
v letech 1956-1960 byla SI sekunda jako 1⁄31 556 925.9747 roku, přitom si všimněte, že už sekunda nijak nesouvisí s délkou dne
a pro pamětníky tu už od roku 1960 máme sekundu podle Cs 133, zatím žádná lepší definice není třeba, ale velmi pochybuji, že bychom se vraceli do minulosti a definovali kdykoliv v budoucnosti sekundu podle rotace Země, která se do jisté míry nepředvídatelně mění
-
Lael Ophir (neregistrovaný)
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ě?
-
Karel (neregistrovaný)
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?
-
Filip JirsákStříbrný podporovatel
Je tu ovšem nepatrná naděje, že do té doby většina programátorů pochopí, že oni tu nejsou od toho, aby předělávali reálný svět tak, aby se jim to dobře programovalo – ale naopak, že oni jsou tu od toho, aby psaly takové programy, které správně fungují s reálným světem. Vzhledem k tomu, že ta vychvalovaná číselná soustava pro počítání času je
60×60×(12×2 nebo 24)×7(plus pevné a pohyblivé svátky)×(obvykle 4 až 4.42857143)×(12, někdy i 13)×365(s výjimkou, výjimkou z výjimky a výjimkou z výjimky z výjimky), nepřipadá mi změna té úvodní 60 na(přirozená čísla, obvykle 60)jako nějaká zásadní komplikace. -
ferren (neregistrovaný)
svet tu neni proto aby to mel nejaky retardovany informatik jednoduchy...normalne 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
-
Santiago (neregistrovaný)
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.
-
robotron (neregistrovaný)
V ITU se to diskutovat muze, osobne si myslim, ze pro ucely telekomunikaci by taky bylo lepsi jet vsude v TAI. At uz jde o tarifikaci hovoru nebo treba zacatky/konce audio/video spotu v rozhlase a televizi, i tam vsude nadela nejmin skody pocet sekund od pocatku sveta s tim, ze prevody na UTC (a mistni pasmovy cas) je lepsi resit na vyssi urovni mimo telekom infrastrukturu.
Nicmene ITU (a narodni telekomunikacni urady) nejsou ti, alespon v zemich naseho kulturniho okruhu, kdo urcuji cas. Za ten zodpovidaji narodni metrologicke ustavy. A ty samozrejme resi spoustu zasadnich zmen, kvuli kterym je treba casto cestovat a flamovat s doktorandkama na strechach hotelu. Z poslednich udalosti vzpomenme napriklad pro tuto diskusi usmevne pripadnou redefinici SI sekundy jako takove (pa pa, cesium), a nebo z toho, co me zaujalo nejvic, redefinici kilogramu -- ze by po vice nez sto letech slo platinovy zavazi pod poklopem na sejry do duchodu?
Zajimavost: ten stavajici kg ma tu neprijemnou vlastnost, ze podle vsech mereni s postupem casu ubejva na hmotnosti. Patrne se z nej uvolnule plyn, zachycenej ve slitine pri odlevani odlitku. Jak uz nekdo vzpomenul vyse, je to celkem problem, protoze kvuli takovyhle prkotine napriklad neustale driftujou vsechny fundamentalni fyzikalni "konstanty", jako je treba hmotnost protonu nebo Planckova konstanta. Jenom proto, ze posukum ve skrini zvetrava zavazi.
-
robotron (neregistrovaný)
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.
-
robotron (neregistrovaný)
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.
-
-
robotron (neregistrovaný)
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 $.
-
Lol Phirae (neregistrovaný)
Nesouhlasil, coz je podle me blbe; myslim, ze prijde den, kdy to zas po PHK nekdo bude muset predelat.
Jojo, to takhle přijde akademik a začně vykládat, jak to všichni dělají blbě, protože to nefunguje s krávovinou, kterou akademik vymyslel (přestupná sekunda) a hrozně se diví, že je nepochopen.
-
-T- (neregistrovaný)
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.
-
Ondra Satai NekolaZlatý podporovatel
Je takove vcelku uzitecne pravidlo: "pokud je to tezke, tak to delej co nejcasteji." Trebas integrace jsou tezke a tak delej CI.
A tady mi to prijde jako ten samy pripad - cim casteji se to bude delat, tim rychleji se najdou problemy, ktere se pri pristi zmene uz neprojevi. Lepsi co par let narazit na par chyb nez jednou za sto let schytat vsechny nahromadene..
