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

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

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?

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

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

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

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.

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.

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 ?

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.

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.

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

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

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?

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.

Tak, spravne nacasovany restart to jisti. :-)

zeby hromadnej update kernelu? :)

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.

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

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

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.

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

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

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.

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.

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.

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.

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

lupa se tim uz take ridi ze?

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

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

bohuzel nemam sanci overit, ze si nebudete googlit

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.