Vlákno názorů k článku
Google „rozmaže“ přestupnou sekundu 31.12.2016 do 20 hodin od JD - Pouceni: nepouzivejte NTP servery googlu. Protoze ukazovat 20...

WTF? Přestupná sekunda byla 2012 i 2015.

Nebyla, byla presunuta na 2016.

Ale nic nebylo přesunuto... https://www.ietf.org/timezones/data/leap-seconds.list

Co to meleš, vorechu? Dotedka si pamatuju strhující článek na roštu který popisoval lov na přestupnou sekundu. Napětím jsem ani nedychal.

ja si naopak pamatuji čekání na přestupnou sekundu:)

GPS nepouziva prestupne sekundy a ma aj iny start epochy.

Je spousta reprezentaci, ktere s prestupnou sekundou zadny problem nemaji, treba nejstarsi unixova klasika, pocet sekund od 1.1.1970

OK, tam mi převeď 1230768000 na UTC.

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.

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í.

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.

Prosímtě, a už mi teda převedeš ten shora uvedenej TT na "legální čas"? Která je ta správná funkce? Aha, hovno. Njn, akademici.

Tak mi rekni, pro jakou zemi. A nebo pouzij https://cr.yp.to/libtai.html

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.

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.)

Kde se používá zimní čas?

Slovesný tvar, jenž jsem použil, se v lingvistice nazývá prézens imperfektiva.

To je zas pravda, to uznávám.

P.S.: ja treba spoustu cinnosti na svem pocitaci provadim v casove zone "Praha/Berlin/Pa­riz/..". 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.

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?

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.

Zeptám se znova, už jsi vyřešil ten bug?

230768000 == 2008-12-31T23:59:60.0
230768000 == 2009-01-01T00:00:00.0

Jestli ne, tak nám tady prosímtě přestaň jako "řešení" radit kundoviny, kde nejsem schopen určit, jestli se něco stalo v jednom roce nebo až v tom dalším.

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.

Nojo, to je jen taková menší chyba, že se ztrácí informace, no. Jestli se něco stalo letos nebo loni, dyť to je jedno, žejo.

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.

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).

> Pak je to spatne.

Je, ale udělat to správně by znamenalo neúnosně zvýšit komplexitu kódu.

> Takovy system se pravdepodobne ekvivalentne podela, az Putin/EU/PSP zrusi letni cas, nebo zmeni den, kdy nastava a konci.

Nepodělá, docela mi to s tím funguje.

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.

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.

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.

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.

> Proste at jedou vnitrne v TAI a maji naprostej klid.

V TAI nejede zbytek světa a půl minuty už je moc velký rozdíl. A bohužel automatický přepočet často rozumně dělat nejde, nebo by to znamenalo moc velký oser.

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.

> 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.

Napadlo tě aspoň na vteřinku, že na to, co tobě a tvým aplikacím vadí a nevadí a co tobě a tvým aplikacím stačí a nestačí s.re pes? Napadlo tě někdy, že ty a tvé aplikace nejsou ani pára na h.vnem z toho, co všechno různí lidé na světě dělají a co se dělat dá?

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.

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 slunci

Ty č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.

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).