Názory k článku Přestupná sekunda prověří servery v noci na 1. července 2015

Co automatické úsekové radary? Zohlední, že jsem úsek projel od 01:59:55 do 02:00:05 za 11 s, nebo mi vypočtou rychlost na 10 s, tedy o 10 % vyšší? Zkusil bych provozovatele buzeradarů potrápit dotazem - pro redakci tip na další článek.

Prestupny den se vklada kvuli obehu zeme kolem slunce, prestupna sekunda kvuli obehu rovniku kolem osy zeme.

Zatimco doba obehu kolem slunce se velmi pomalu zkracuje (zmensuje se polomer), rychlost zemske rotace osciluje (zrychluje i zpomaluje, dlouhodobe zpomaluje) v zavislosti na silnych zemetresenich, slapovych jevech zeme<->mesic atd... a kdyz se doba obehu rovniku prodlouzi (v souctu za uplynule obdobi) o vic jak jednu sekundu (proti hvezdnemu pozadi), dojde k vlozeni prestupne sekundy.

Problem bych laicky videl v tom, ze spousta programu bude mit jako validni rozsah pro vteriny 0-59, tim padem kdyz mu v nejake operaci prijde hodnota 60 (treba si bude chtit ulozit cas registrace nekoho nebo tak neco) tak se z toho teoreticky muze po.....

Fantasticky titulek a vypovidaci hodnota clanku nula. Servery se bezne mohou rozchazet i o nekolik vterin a pokud jde o bezny server, tak se samozrejme nic nestane. Problemy mohou delat autentizacni metody zavisle na presnem case, ale ani ty by ta 1s asi nerozhodila. Maximalne se ten den vsude vynuti synchronizace s NTP a jede se dal.. Nebo je to jinak?

zeby hromadnej update kernelu? :)

Pokud synchronizuji pres ntpd a zdroj mi utece o sekundu, ntpd zacne zrychlovat ci zpomalovat systemove hodiny, aby to dorovnal. Zadny skok se nekona, k tomu by doslo pri vetsim rozdilu, nebo synchronizaci pomoci ntpdate.

Jina vec je ta, ze se skokovou zmenou casu urcitym zpusobem vetsina systemovych programu pocita.

Jenze tady zdroj o sekundu neutece. NTP i jadro s prestupnou sekundou pocitaji, takze k zadnemu posunu ci rozsynchronizovani by nemelo dojit. K problemu dojde az na rozhrani mezi jadrem a aplikacema, kde proste cas 2015-06-30 23:59:60 a 2015-07-01 00:00:00 je reprezentovan stejnou hodnotou unix time.

No, tohle není úplně přesné. Zaprvé, problém není, že se to vložení vteřiny navíc naplánuje předem, ale v implementaci toho naplánování. Zadruhé, v odkazovaném článku se píše, že jde o livelock, což není pravda - jde o deadlock, i když se spinlocky. Přímo v tom článku je uvedena posloupnost volání, kde je krásně vidět, jak dvě vlákna zamykají dva různé zámky v různém pořadí, a to je konečná. To je častá, až učebnicová, příčina deadlocku.

rekl bych ze buzoradar nebude vedet ze se neco posouva o vterinu, tj bude to jedno, max pak nebude sedet prestupek o prave tu vterinu.

Tolerance jsou tak velké, že pokud vám bude zjištěn přestupek kvůli sekundě navíc, tak jste se ho jistě dopustil i s přesným měřením. Akorát by vám "prošel".

Jednotka casu je sekunda, o tom neni pochyb, ale neznam duvod, proc trvat na vterine (namisto sekundy) jako korektni jednotce pro uhel. To je nejake ceske specifikum? Kde je to vubec kodifikovane? AFAIK oficialni jednotka pro uhel je radian, a ten je metricky.

Například, pokud používáte linux, tak pokud provedete aktualizaci systému v následující době, tak se pravděpodobně patřičně zaktualizuje i balík tzdata, který obsahuje informace o vkládaných přestupných sekundách a jak systém při přepočtu time_t čítače to má zohledňovat.
Pokud systém bude používat NTP, tak dostane aplikace takovouto posloupnost časů, jestliže by se ptala po sekundě:
2015-06-31 23:59:59 UTC
2015-06-31 23:59:59 UTC
2015-07-01 00:00:00 UTC
Jinak třeba kernel vypisuje do logu, když dojde k přestupné sekundě. V starších kernelech byla chyba, takže to dokázalao na tom i shodit celý systém. :-)

Nevím, jak jiné databáze, ale typ DATATIME v INFORMIXU má pro pole vteřin rozsah 0-61 (dříve se Země točila rychleji, tak se dokonce občas přidávaly dvě přestupné vteřiny).

Jinak ty přestupné vteřiny jsou evidovány a systém by měl správně ukazovat čas i zpětně a stejně tak by je měl uvažovat při počítání počtu vteřin mezi dvěma časovými údaji. Tedy by měl spočítat, že rozdíl mezi 2015-07-01 00:00:01 a 2015-06-30 23:59:59 jsou tři vteřiny a ne dvě, jak by naivně člověk čekal.

Může vám to připadat malicherné, ale když si astronomové nasměrují dalekohled na stejné místo, jak před deseti lety, a systém jim tam hodí časový údaj o pár vteřin vedle, tak se koukaj někam úplně jinam, než chtěli. Stejně tak třeba GSM vás kvůli zapomenuté přestupné vteřině pošle o stovky kilometrů jinam. A podobně jsou na přesných časech a časových rozdílech závislé spousty oborů a aplikací.

> dříve se Země točila rychleji, tak se dokonce občas přidávaly dvě přestupné vteřiny

Ne.

> Jinak ty přestupné vteřiny jsou evidovány a systém by měl správně ukazovat čas i zpětně a stejně tak by je měl uvažovat při počítání počtu vteřin mezi dvěma časovými údaji.

Tohle mi na celém tom principu přijde nejdebilnější. Přestupné sekundy se vyhlašují něco jako necelý rok dopředu, takže výsledkem je, že 1) systém co je chvíli offline se o ní nedozví a pak to dělá bordel, 2) nejde říct, kolik hodin bude za rok, protože tam mužná někdo přidá přestupnou sekundu a možná ne.

Podle mě tyto dva problémy za to, že si můžeš spočítat, kde je Slunce na daném poledníku, nestojí. Ujede to asi o pět [časových] minut za tisíc let. Pokud se do té doby lidstvu podaří lítat na jiné planety, tak stejně bude potřeba časový systém úplně změnit.

> Stejně tak třeba GSM vás kvůli zapomenuté přestupné vteřině pošle o stovky kilometrů jinam.

1) GSM je ten systém pro mobily. Ten má čas kvůli synchronizaci BTSek a poloha může ujet maximálně o 35 km, pak se síť rozpadne :)

2) 1 sekundy je 300'000 km, ne jenom stovky

3) Asi jsi měl na mysli GPS. Tam se právě kvůli těmto problémům používá čas bez přestupných sekund.

> pak se síť rozpadne :)

To jsem asi trochu zveličil. Spíš jenom bude problém s handoverem.

me nebude stacit jen vase ujisteni, proto se ptam, napiste mi ten rozdil...

bohuzel nemam sanci overit, ze si nebudete googlit

Pokud se přidávají dvě přestupné sekundy, tak se nepřidávají najednou, ale jedna v polovině roku a jedna na přelomu roku. Naposledy se to ale stalo v roce 1972.

Systém GPS s tím sice počítá a systém jako takový se s tím vypořádá, ale v u praktických implementací problémy skutečně nastat mohou. Když se naposledy přidávala přestupná sekunda (léto 2012), navigace mi pak ještě skoro týden ukazovala polohu necelých 400 metrů západně od místa, kde jsem skutečně byl (což odpovídá přibližně 370 metrům, o které se Země otočí za jednu sekundu na příslušné rovnoběžce). Podle supportu stačilo provést update informací o poloze satelitů ("quick gps fix"), jenže jsem byl bohužel zrovna ten týden na dovolené, takže to nešlo.

Nerozpadne. Bere čas na synchronizaci pro FHSS (freqency hopping) z GPS.

Já jsem to pochopil tak, že předřečník mluví o situaci, kdy bude na některých BTS čas o sekundu jinak. Pak se podle mě hopping nedokáže syncnout.

> 1

A já jsem navrhoval, že než mít nedeterministický (!) čas založený na náhodných výkyvech Země by bylo nejlepší těch pár minut za tisíciletí neřešit.

> 2

A nebo bere čas z GPS přijímače, který předem přestupnou sekundu oznámit neumí (zažil jsem, profesionální navigační systém). Samozřejmě můžeme prohlásit, že je to chyba protokolu/imple­mentace. Mně ale přijde, že tohle protokol naprosto zbytečně zesložiťuje.

> takže systém, co je chvíli (=cca rok a více) offline a připojí se před přestupnou sekundou má šanci zjistit, co se bude dít

Ne. Vy vložíte flashku se soubory do systému, který je a bude offline, načež dojde k nekonzistenci timestampů.

Není nutná přesnost, je jen potřeba, aby seděl třeba unixový timestamp u mtime souboru s datem v UTC, které si ukládá databáze.

A to je přesně ta zbytečná komplikace, o které jsem mluvil ;)

Přestupná sekunda se vkládá kvůli tomu, že Země postupně zpomaluje a den už není tak dlouhý, jak by měl být - 86400 s. Kupodivu to neznamená, že za těch pár let se Země zpomalila o sekundu. Jen za těch pár let rozdíl na tu jednu sekundu narostl (zjednodušeně).

Postupem času je potřeba tu sekundu vkládat čím dál častěji. Sekundu je možno i ubrat, kdyby bylo potřeba. Ale ještě se to nikdy nestalo a asi ani nestane.

Přestupný den se do kalendáře vkládá kvůli tomu, že počet dní v roce není celý. Je to zcela jiný problém.

To se jako seřizují atomové hodiny dle otáčení Země? A to jak?

No když některému sw přijde čas 23:59:60, tak se s tím nemusí vypořádat, protože nemusí být připravený na takový nesmyslný čas.

Hezky to vysvětlil? Cituji: "...tak se občas stane, že [planeta] se někde předběhne a někde zdrží"

A proto, milé děti, vkládáme přestupný den a někdy i přestupnou sekundu! Když se planeta někde na chvíli zastaví...

Nebo jak to jako myslel?

obecne cestina nerozlisuje nebo nedokaze rozlisit mezi bitem a bytem... zeptejte se normalniho prumerneho cloveka..

lupa se tim uz take ridi ze?

ja nechapu v cem je problem servery si prece obcas serizuji cas podle nejakych atomovych hodin a ne jen o 1 vterinu a nezhrouti se z toho?

i nastenne hodiny vedi , ze minuta ma 60s a ne 61s . Kdyz se rozsteluji, sesteluji se rucne zpet .

To same bych videl i u systemu.
Nebo vam se snad sesype server kdyz bezi o minutu jinak ?

Ono se to taky ve vetsine pripadu tak chovat bude - POSIXove rozhrani (pouzivane napr. v Linuxu) s prestupnou sekundou nepocita, takze pro aplikacni software se to projevi tak, ze nasledujici sekunda (2014-07-01 00:00:00) se zopakuje dvakrat. Vzhledem k tomu, ze mame jeste milisekundy, tak v podste dojde ke skoku o sekundu zpet a poruseni monotonosti casu, coz nekteremu softwaru muze delat potiz.

Druha vec jsou potencialni implementacni problemy v jadre, kdy se ta sekunda zamicha i do veci, kam by nemela.

Ty servery zadny problem nemaji, jediny problem by pro ne byl posun casu do minulosti => pokud by existovaly zaznamy novejsi nez aktualni cas. Opacne by to technicky problem nebyl, pouze z hlediska bezpecnosti by to nebylo koser. Ale prave toto resi synchronizace casu regulaci rychlosti hodin => systemovy cas je kontinualni, coz je podstatne, nikoli to, ze je absolutne presny.

U oběhu Země kolem Slunce nejde o to, že se zkracuje, ale že jeho délka není celý počet dnů (přibližně 365.24), zatímco u kalendářního roku celý počet dnů potřebujeme. Juliánský kalendář vkládal jeden den každý čtvrtý rok, takže měl střední délku roku 365.25 dnů a časem se začal viditelně rozcházet (viz např. VŘSR v listopadu). Gregoriánský oproti němu ubírá tři dny za 400 let a jeho střední délka roku (365.2425 dnů) je natolik blízko skutečné hodnotě, že případné další korekce nebude potřeba řešit ještě hodně dlouho (a pak už začne hrát roli i to zpomalování zemské rotace).

Mě zajímají databáze. Tam používám smalldatetime, ten vteřiny nepoužívá. Tuším, že budu moci klidně spát?

Pokud system hodiny synchronizuje pomoci NTP, tak tam by odchylka vubec nemela vzniknout, nebot prestupna sekunda je tam explicitne osetrena jako specialni pripad,

Pointou to nebylo, ale je to důvod, proč se vkládají přestupné dny (a proč zrovna tak, jak se to dělá). Odchylky vzniklé systematickými nebo náhodnými změnami rychlosti zemské rotace a jejího pohybu jsou tak malé, že nemají šanci nastřádat celý den ani v horizontu tisíců let. Tím spíš, že se korigují (právě tou přestupnou sekundou) už poté, co se nastřádá sekunda.

Kopodivu rozlisuje, a zcela bezne, protoze je to bit a bajt. "Normalni prumerny clovek" netusi co je jedno i druhe.

Tak, spravne nacasovany restart to jisti. :-)

Ad zeme kolem slunce - samozrejme ze pocet dnu presne neodpovida, to ale nebylo pointou (to ze mame kalendar nekompatibilni se zakladnimi prirodnimi cykly, a proto se do nej bastli pravidla o dalsich dnech a vyjimky z vyjimek techto pravidel je druha vec).

Běžné programy berou čas ze systému a ten mít hodnotu 23:59:60 nemůže, takže jediný problém vidím u programů co si sahají pro čas (ntp) a snaží se ho nastavit zrovna když přijde tato hodnota. Ale předpokládám, že ntp klienti to už umí zvládnout, takže já bych laicky řekl, že problém jen tak nenastane, pokud někdo neprovozuje roky nějaký systém bez aktualizací.

tak pokud budou automove hodiny v jednu chvili ukazovat 23:59:60 tak pak to zhrouceni chapu co, ale nechapu, jak je tu jiz psano proc proste neukazuji 2s 23:59:59....

A proc by mu mel system takovy nesmyslny cas nabizet? Zachova se to presne stejne jako pri zcela beznem provozu, pokud system cas nesyncuje, tak pro nej zadna prestupna sekunda nebude existovat a holt bude jeho cas o vterinu jinak (a spis o daleko vic, bezne HW nema zadny uzasny zdroj casu).

Pokud system hodiny nejakym zpusobem synchronizuje, nastane opet zcela standardni situace, kdy vznikne ochylka, ktera bude dorovnana zpomalenim systemovych hodin.

Seřídit otáčení Země oproti atomovým hodinám by totiž bylo poněkud obtížnější :-)

Ahoj,
vydat v odbornem periodiku clanek o prestupne sekunde a v textu pouzivat jako jednotku "casu" vterinu, to je tedy ulet.
I muj 10ti lety syn vi, ze cas se meri v sekundach a ze vterina je obloukova mira, ne casova. Dostal sice za "vteriny" uz par pohlavku, ale uz si to docela dlouho pamatuje.
Opravte to prosim, taha to za oci.