23:59:59 23:59:60 00:00:00

Mezinárodní organizace pro sledování rotace Země a referenčních systémů (IERS) stanovila, že noc z 30. června na 1. července bude o tzv. přestupnou sekundu delší. V roce 2012 měla řada systémů s přestupní sekundou vážné problémy (zprávička).

9.1.2015 10:11 | Ladislav Hagara | Zajímavý článek

Komentáře

[kodl]

Nechápu, jak mizerná jedna sekunda může vážně ohrozit činnost systému.

[Žirafa]

Ze stejného důvodu, proč program může fungovat pouze v sobotu (ostatní dny mají diakritiku).

Je sice hezké, že se datum udržuje například jako počet sekund uplynulých od epochy v 32/64 bitovém intu, když pak stejně potřebujete funkci, která to rozumným způsobem převede na sobotu 9. června 2014 18:59:61.

Takové chyby zanáší do kódu všichni a ti lepší pak nakonec provedou kontrolu / test / poslechnou varování překladače a opraví je. V horším případě se chyby opravují zpětně. Když jsem poprvé slyšel, že minuta v počítači může trvat až 61 (někdo tvrdil, že i 62) sekund, tak jsem si myslel, že jde o vtip. Bohužel naše šišatá nepravidelná planeta se točí pokaždé jinak...

[Ondrej Santiago Zajicek]

Ono v POSIXu se cas/datum udrzuje jako pocet sekund od epochy bez prestupnych sekund, takze prepocet na slozkovy cas je relativne jednoduchy. Negativum ale je, ze prestupnou sekundu nelze reprezentovat v unix time, takze na plne synchronizovanem systemu dojde k sekundovemu skoku zpet v unix time, nejednoznacnostem v timestampech souboru a pod.

[Jendа]

Takové chyby zanáší do kódu všichni a ti lepší pak nakonec provedou kontrolu / test / poslechnou varování překladače a opraví je.

Tohle podle mě nemá řešení. Například nemůžeš nastavit expiraci účtu na 30.6.2016 23:59:59, protože takový čas možná vůbec nebude existovat.

[SUK]

A ty overujes expiraci kazdou sekundu pomoci ekvivalence? ;) Pro zacatek bych zkusil treba "vetsi nebo rovno"? :)

[Jendа]

Ne, ale třeba používám event-based systém (třeba něco jako unixový "at"), který si nastaví na daný čas alarm a spustí nějakou akci (smazání uživatelova home…). Když k času nedojde, alarm se nespustí.

[Heron]

Ne, ale třeba používám event-based systém (třeba něco jako unixový "at"), který si nastaví na daný čas alarm a spustí nějakou akci (smazání uživatelova home…). Když k času nedojde, alarm se nespustí.

WTF? Systém, který by byl implementovaný výše popsaným způsobem by na (běžném x86) hw vůbec nefungoval. Čas se porovnává pomocí větší rovno a daná událost se provede v nebližším možném termínu po nastaveném čase. Systém, který by porovnával čas pomocí = by musel splňovat znaky realime os, aby se proces, který kontroluje čas a onu událost spouští, vůbec v daném okamžiku (např. milisekundě, sekundě, v extrémním případě minutě) dostal k procesoru.

[Jendа]

Systém, který by byl implementovaný výše popsaným způsobem by na (běžném x86) hw vůbec nefungoval.

x86? Not my problem.

Čas se porovnává pomocí větší rovno

OK, má se již provést příkaz v podmínce

if(get_current_time() >= "32.13.2014 25:48:73")

?

Systém, který by porovnával čas pomocí = by musel splňovat znaky realime os, aby se proces, který kontroluje čas a onu událost spouští, vůbec v daném okamžiku (např. milisekundě, sekundě, v extrémním případě minutě) dostal k procesoru.

Není potřeba, aby se dostal k procesoru. Má to HW alarm a udělá to v daný čas interrupt.

[Heron]

OK, má se již provést příkaz v podmínce

Údaj v podmínce neodpovídá žádné definici času kterou já znám, takže je to chyba při validaci vstupních dat nebo chyba při kompilaci.

Jestli to mělo být nakopnutí k tomu, že "já přece taky nevím, jestli bude v 30.6.2036 přestupná sekunda, takže nevím, zda uznat čas 23:59:60, tak bych radil spíše defensivní přístup a danou situaci vůbec nepovoloval / volil větší tolerance. A pokud je nezbytně nutné brát do úvahy každou jednotlivou sekundu, tak program zcela evidentně nemůže používat čas UTC a proto by měl používat nějaký jiný.

[Jendа]

Jestli to mělo být nakopnutí k tomu

Skoro přesně tak :). Ale nešlo mi ani tak o to, jestli povolit 23:59:60, jako spíš jestli povolit 23:59:59. Přestupná sekunda nemusí znamenat jenom přidání ale i odebrání.

No a pak je ještě problém vysvětlit to uživateli (bohatě stačí seznámit ho s timezonami a DST). Ještě štěstí, že ve většině případů sekundy neřeší a u toho nešťastného navigačního systému po seznámení s problematikou řekli, že to z optické podstaty zařízení provozují jenom za denního světla a sekunda je za tmy :)

[Heron]

Přestupná sekunda nemusí znamenat jenom přidání ale i odebrání.

Ano, to je jasné, ale přece to nic nemění. Pokud někdo zadá časový údaj 23:59:59 a ona zrovna nebude, tak se nic neděje, program to provede v čase 00:00:00 následujícího dne. To je ten defensivní přístup. Případně, vzhledem k tomu, že se to vyhlašuje dostatečně dlouho dopředu, můžu uživatele informovat o tom, že jeho časový údaj je neplatný a požádat ho o změnu, případně změnu provést automaticky a jen uživatele informovat apod.

Poznámky pro dopravce: Nedávat je blízko k sobě!

Přepravuješ plutonium?

[Jendа]

Pokud někdo zadá časový údaj 23:59:59 a ona zrovna nebude, tak se nic neděje, program to provede v čase 00:00:00 následujícího dne.

Nebo 23:59:58…

Já vím jak to řešit (u aplikací, kde nejsou potřeba desítky milisekundových timestampů za sekundu). Proč ale pak děláme tuhle šaškárnu s tím, aby byl čas na sekundy přesně, když to pak stejně systém prskne o sekundu sem či o sekundu tam a když to někdo už fakt přesně potřebuje, doporučíme mu TAI?

Přepravuješ plutonium?

Ne, (obohacený) uran. Plutonium je jedovaté.

[Heron]

Proč ale pak děláme tuhle šaškárnu s tím, aby byl čas na sekundy přesně

Na to je zcela stejná odpověď, jako na otázku proč se vkládá přestupný den. Prostě proto, aby lidský umělý kalendář seděl s fyzikální realitou. Realita je taková, že jeden oběh kolem Slunce netrvá přesně jeden rok, takže se občas vkládá den, stejně tak rotace Země kolem své osy není přesně jeden den, takže se občas vkládá jedna sekunda (to že by se někdy ubírala je krajně nepravděpodobné).

A vzhledem k tomu, že jak oběh kolem Slunce, tak i rotace není stabilní, tak není možné udělat takový kalendář, aby to přesně vyšlo. Proto je potřeba jej korigovat.

Lidstvo by se muselo rozhodnout a zcela opustit systém navázaný na fyzikální realitu a až potom by se mohla prosadit nějaká jiná časová soustava. Ale rozhodně to na to nevypadá.

A já bych byl všemi deseti pro, aby se opustila šedesátková soustava (i když má své výhody) a čas se počítal normálně pomocí násobků SI (taková megasekunda zní docela dobře).

Ne, (obohacený) uran. Plutonium je jedovaté.

Tak to jo, to schvaluju.

[Jendа]

No jo, jenže u přestupného roku jsme si spočítali, kolik to asi tak bude, vyjádřili jsme to pomocí několika pravidel dělitelnosti a teď podle toho jedeme. Přestupná sekunda se vkládá stylem „hmm, za půl roku by se mohla přidat“.

Navíc přestupná sekunda řeší minuty za tisíciletí - jenže většina populace nejspíš žije v časovém pásmu, kde je odchylka od slunečního času půl hodiny a víc a ještě k tomu půlku roku používají DST, které to šoupne ještě o hodinu mimo.

[Filip Jirsák]

Ano, přestupná sekunda se vkládá tak, jak popisujete. Děje se tak už přes čtyřicet let, tak se s tím smiřte. Ono je celé to lidské počítání času nesmyslné, dělení na šedesátiny a dvanáctiny, různě dlouhé měsíce, měsíce ani roky nejsou zarovnané na týdny... Jenže lidé jsou na to zvyklí, bez problémů to zvládají, takže těžko najdete přesvědčivý důvod, proč to měnit.

Přestupná sekunda sice řeší minutu za dvě století, ale ono je mnohem lepší řešit ty korekce průběžně způsobem, který všichni znají a pravidelně se opakuje, než se to pokoušet řešit jednorázově nějakým nesystémovým zásahem.

[Jendа]

Ano, přestupná sekunda se vkládá tak, jak popisujete. Děje se tak už přes čtyřicet let, tak se s tím smiřte.

Způsobuje to situace, které z principu nelze řešit, i kdybychom prohlásili, že tomu programátor má věnovat rok.

Ono je celé to lidské počítání času nesmyslné, dělení na šedesátiny a dvanáctiny, různě dlouhé měsíce, měsíce ani roky nejsou zarovnané na týdny...

Je to pakárna, ale alespoň dokážete spočítat, jak se to bude chovat (v rámci platnosti systému) neomezeně do budoucnosti. A kód který to korektně počítá není zas tak dlouhý.

Přestupná sekunda sice řeší minutu za dvě století, ale ono je mnohem lepší řešit ty korekce průběžně způsobem, který všichni znají a pravidelně se opakuje, než se to pokoušet řešit jednorázově nějakým nesystémovým zásahem.

Stále nejsem přesvědčen, že ten zásah vůbec bude potřeba.

[Heron]

Způsobuje to situace, které z principu nelze řešit, i kdybychom prohlásili, že tomu programátor má věnovat rok.

Pokud je to situace, kterou nelze řešit, tak je zbytečné ji řešit a je hloupé dávat tomu programátorovi rok.

[Jendа]

Jistě. To bylo pro kontrast s níže uvedeným názorem, že je to chyba v implementaci.

[Filip Jirsák]

Způsobuje to situace, které z principu nelze řešit, i kdybychom prohlásili, že tomu programátor má věnovat rok.

Nikoli, pouze to zviditelňuje chyby, které se mohou projevit i jinak.

Je to pakárna, ale alespoň dokážete spočítat, jak se to bude chovat (v rámci platnosti systému) neomezeně do budoucnosti.

Což je sice hezký akademický příklad, ale v praxi je to úplně k ničemu.

Stále nejsem přesvědčen, že ten zásah vůbec bude potřeba.

Nebude, protože se ty korekce dělají průběžně. Holt lidé z nějakých důvodů chtějí mít počítání času svázané s jevy jako je vzájemná poloha Země a Slunce, tak se jen řeší, jak to organizačně zajistit. S tím, jak se naše měření postupně zpřesňuje, se zjistilo, že je potřeba to korigovat přestupnými roky, pak přestupnými roky s pravidlem 4 ano, 100 ne a 400 ano, a posléze že je potřeba to dál korigovat přestupnými sekundami. Ano, mohli bychom mít i čas na přírodních jevech zcela nezávislý. Ale nedávalo by smysl mít čas nepřesně svázaný s přírodními jevy.

[Jendа]

Holt lidé z nějakých důvodů chtějí mít počítání času svázané s jevy jako je vzájemná poloha Země a Slunce, tak se jen řeší, jak to organizačně zajistit.

Tak pak když už řešíme přestupnou sekundu by to chtělo vyřešit i hodinový úhel (odchylka 15 minut dvakrát ročně), nedostatečnou granularitu časových pásem (odchylka až 2 hodiny při současné implementaci a až 30 minut při hypotetické implementaci podle poledníků) a letní čas (odchylka 1 hodina). Všechny tyto jevy jsou horší než chyba kterou by naakumulovalo zanedbávání přestupné sekundy od zavedení Gregoriánského kalendáře a ještě asi tak tisíc let do budoucnosti.

[Filip Jirsák]

Vůbec nejde o ty lokální odchylky. Jde o to, aby seděl celek. Jako u přestupného roku. Nikomu nevadí, že se zimní slunovrat posouvá v rozmezí dvou dnů. Vadilo by, kdyby se trvale posouval jedním směrem, protože by to postupně vedlo k tomu, že zimní slunovrat budeme mít v létě.

[Jendа]

Vadilo by, kdyby se trvale posouval jedním směrem, protože by to postupně vedlo k tomu, že zimní slunovrat budeme mít v létě.

Vadilo by to i v případě, že by se posouval tak pomalu, že by do toho léta docestoval v roce 100000? (slovy sto tisíc) Myslíte, že v té době budou lidi řešit, že v roce 2014 byl zimní slunovrat 21. prosince?

[Heron]

Musím říct, že tato diskuse mi pomohla pochopit některé tvé komentáře v jiných a s tématem zcela nesouvisejících diskusí.

Jsou lidé, kteří chtějí dělat věci co možná nejlépe v rámci současných možností a ti se nesmíří s tím, že když už máme občanský čas definovaný v závislosti na pohybech nebeských těles, tak budeme zcela ignorovat nějaké nové přesnější měření a tvářit se, že posun o hodinu za 7200 let je vlastně málo a nebudeme to řešit.

Stejně tak bychom mohli ignorovat to, že Země neoběhne Slunce přesně za rok, vždyť je to také jen o malý kousek.

Prostě, pokud občasnký čas definujeme nějak, nemůžeme ignorovat vlivy, které vedou k tomu, že se ten čas od té definice měřitelným způsobem posune.

[Jendа]

Musím říct, že tato diskuse mi pomohla pochopit některé tvé komentáře v jiných a s tématem zcela nesouvisejících diskusí.

Těší mě :)

Prostě, pokud občasnký čas definujeme nějak, nemůžeme ignorovat vlivy, které vedou k tomu, že se ten čas od té definice měřitelným způsobem posune.

Tuto možnost jsem zmiňoval o dva komentáře výš. Kdyby někdo důsledně lpěl na řízení se Sluncem, chápal bych to. Pak by ale musel lpět například na místním čase místo časových pásem.

Stejně tak bychom mohli ignorovat to, že Země neoběhne Slunce přesně za rok, vždyť je to také jen o malý kousek.

To je o několik řádů větší odchylka než přestupná sekunda. Ale nevadilo by mi to.

[Filip Jirsák]

Kdyby někdo důsledně lpěl na řízení se Sluncem, chápal bych to. Pak by ale musel lpět například na místním čase místo časových pásem.

Ale vůbec nejde o to, aby občanský čas odpovídal postavení Slunce v každém okamžiku. Jde o to, aby mu odpovídal dlouhodobě, aby systematicky neujížděl jedním nebo druhým směrem. Je to jako když jedete autem v jízdním pruhu - nepotřebujete být v každém okamžiku přesně ve středu toho pruhu, ale pokud se budete systematicky od středu neustále vzdalovat, skončíte ve škarpě nebo v protisměru. No a je lepší se kolem toho středu držet průběžně, ne čekat, až začnete pravým kolem lízat krajnici, pak myškou přejet levým kolem na středovou čáru a zase pomalu klouzat doprava.

[Ondrej Santiago Zajicek]

Jde o to, aby mu odpovídal dlouhodobě, aby systematicky neujížděl jedním nebo druhým směrem.

Pri korekci pomoci zmen casovych zon by take dlouhodobe neujizdel jednim nebo druhym smerem.

[Jendа]

Jenže vy se přibližujete k metr vzdálené krajnici o milimetr za 100 kilometrů a po 500 kilometrech nejspíš stejně budete muset odbočit k benzínové pumpě a pak na silnici znova najedete doprostřed.

[Filip Jirsák]

To je možné. Ale když o té chybě vím teď, připadá mi správné teď ji korigovat. Řešení "zatím je dost času, ono se to do té doby nějak vyvrbí" se aplikovalo na w2k a nebylo to zrovna slavné.

[Ondrej Santiago Zajicek]

Jsou lidé, kteří chtějí dělat věci co možná nejlépe v rámci současných možností a ti se nesmíří s tím, že když už máme občanský čas definovaný v závislosti na pohybech nebeských těles, tak budeme zcela ignorovat nějaké nové přesnější měření a tvářit se, že posun o hodinu za 7200 let je vlastně málo a nebudeme to řešit.

Otazna nezni zda ignorovat presnejsi mereni. Otazka zni, zda vubec mit obcansky cas definovany v zavislosti na pohybech nebeskych teles. IMHO to je hloupost uz od doby, co sekunda prestala byt odvozenou jednotkou od aktualni delky stredniho solarniho dne (tedy ~60 let zpatky) a stale se zakladni casovou jednotkou.

tvářit se, že posun o hodinu za 7200 let je vlastně málo a nebudeme to řešit

S takovym postojem bys mel odmitnout soucasny gregoriansky kalendar (ktery je jen priblizny a casem oddriftuje) a navrhnout vkladani prestupneho roku podle astronomickych pozorovani (podobne, jako to ma treba tradicni iransky solarni kalendar).

[Filip Jirsák]

Pokud by občanský čas neměl být definován v závislosti na pohybech nebeských těles, pak vůbec nedává smysl používat v občanském čase rok, který má někdy 365 a někdy 366 dní, používat v něm měsíce, které mají od 28 do 31 dní, a používat k určování času v rámci dne dvanáctkovou, čtyřiadvacítkovou a šedesátkovou soustavu, když všude jinde používáme desítkovou.

[Ondrej Santiago Zajicek]

Je rozdil mezi tremi pripady:

1) byt definovan v zavislosti na pohybech nebeskych teles

2) byt definovan nezavisle na pohybech nebeskych teles, ale pritom mit definici takovou, aby pohyb nebeskych teles zhruba aproximovala (i treba s nejakym malym driftem)

3) byt zcela odtrzeny od pohybu nebeskych teles s vyjimkou historickych souvislosti

UTC s prestupnou sekundou je pripad 1).

Juliansky i Gregoriansky kalendarni rok je pripad 2). Pokud bys chtel kalendar, kde je rok definovan v zavislosti na pohybech nebeskych teles, tak se podivej na tradicni iransky kalendar.

Mesice jsou pripad 3), tam odstranil zavislost na pohybech nebeskych teles uz Julius Caesar (zavedenim Julianskeho kalendare) a vzhledem k velke odchylce (1/3 mesice za rok) to prakticky okamzite oddriftovalo, takze tam zadna prakticka souvislost neni a nikomu to moc nevadi. Pokud bys chtel kalendar, kde je mesic definovan v zavislosti na pohybech nebeskych teles, tak se podivej na islamsky kalendar.

Deleni dne obskurnima soustavam je historicky balast, ale pochybuju, ze by pouziti konkretnich hodnot (12, 24, 60) vubec kdy melo souvislost s pohybem nebeskych teles.

[Filip Jirsák]

Juliánský kalendář byl snahou o 1), a gregoriánský to pak korigoval, aby se 1) lépe přiblížil. 2) je nesmysl, zvlášť s přihlédnutím k tomu, že malý drift znamená, že aproximace bude postupem času úplně nesmyslná.

Ty "obskurní" soustavy nemají souvislost s pohybem nebeských těles, ale s tím, že jsou to všechno mnohem rozumnější soustavy, než desítková. Jenže přejít dnes na dvanáctkovou nebo šedesátkovou soustavu je ještě větší utopie, než přejít na "hvězdné datum".

[Ondrej Santiago Zajicek]

Myslim, ze rozdil mezi definici, ktera primo zavisi na astronomickych jevech (a tedy je ji treba soustavne experimentalne vyhodnocovat), a definici, kde neni zavislost, jen historicka souvislost, je zrejmy. Jiny priklad je historicka sekunda, ktera zavisi na delce stredniho solarniho dne (pripad 1), a soucasna sekunda, ktera zavisi na rychlosti jadernych jevu v Cs-133.

Jak Juliansky tak Gregoriansky kalendar ma maly drift proti skutecnemu obehu zeme.

[Ondrej Santiago Zajicek]

soucasna sekunda, ktera zavisi na rychlosti jadernych jevu v Cs-133

(pripad 2)

[JS1]

Otazka zni, zda vubec mit obcansky cas definovany v zavislosti na pohybech nebeskych teles.

Urcite je to takova hloupost? U mesicu asi ano, ale u dne a roku je IMHO prakticke mit udalosti odpovidajici rocnimu obdobi nebo denni dobe zhruba ve stejnou dobu (veci jako prazdniny, vanoce, nocni klid...).

[Ondrej Santiago Zajicek]

Urcite je to takova hloupost?

Rozebiram to tady. Pro zajisteni teto korespondence neni treba explictni zavislost (pripad 1), staci nezavisla aproximace (pripad 2).

[JS1]

S tim bych souhlasil, jenom mi tedy neni jasne, co bys tedy prakticky prosazoval. Zruseni tech prestupnych vterin? S tim bych nemel problem, ale neznam hlavni argument pro.

[Ondrej Santiago Zajicek]

Zruseni tech prestupnych vterin?

Ano. A akumulovanou odchylku pripadne resit posunem casovych zon, pokud tech nekolik minut za staleti bude lidi trapit.

S tim bych nemel problem, ale neznam hlavni argument pro

Predvidatelna casova skala. Odstraneni zbytecne komplexity a s ni spojene problemy.

[JS1]

Myslel jsem "neznam hlavni argument pro zavedeni postupnych vterin". Ty opacne jsou mi celkem jasne.

[Filip Jirsák]

Vadilo. Ne nám, ale proč to dnes neřešit jak nejlépe umíme? Koncem roku 1999 by spousta lidí ocenila, kdyby se dříve k w2k nepřistupovalo stylem "nám to dnes nevadí".

[Jendа]

Vadilo.

Nedokážu si představit proč. Myslíte, že lidem bude vadit oslava Vánoc (které nejspíš už nebudou existovat) nebo uzavření fiskálního roku v létě? Nebo že budou chtít používat 10000 let staré zemědělské tabulky?

Ne nám, ale proč to dnes neřešit jak nejlépe umíme?

Protože navržený způsob řešení přináší problémy, které jsou dle mého názoru mnohem větší než ty, které by přineslo, že červnu 100000 bude sněžit a v prosinci bude horko (hint: Autrálie).

[Jendа]

(nelpím na vysvětlení analogie s roky, kterou jsme primárně neřešili; pokud mi rovnou vysvětlíte, proč vadí, že v roce 50000 budu mít Slunce nad hlavou v 18:00, budu ještě radši)

[Filip Jirsák]

Nedokážu si představit proč.

Protože by spousta věcí přestala dávat smysl. Myslím, že s gregoriánskou korekcí juliánského kalendáře se lidé netrápili jen tak, že zrovna neměli do čeho píchnout. Pokud by to nevadilo, nemá smysl vůbec používat časový systém navázaný na postavení Země a Slunce. Jenže poptávka po tom opustit tenhle systém není velká.

[Jendа]

Pokud si pamatuji z dějepisu, trápili se s Vánoci a Velikonocemi a s ujížděním tabulek kdy se má zasít a sklidit která plodina. Tradice Vánoc a Velikonoc stihla za posledních 400 let dost zdegenerovat a zemědělství se mechanizací a hnojivy změnilo úplně. A to je 1000 a 400 let, ne 10000.

(a jestli můžete spíš ty příklady na poledne v 18:00 za 50000 let, díky)

[Filip Jirsák]

Rituály spojené s tím,že už máme půlku zimy za sebou, a že už zima skončila a začíná jaro, nemá smysl slavit uprostřed léta nebo na podzim. A je celkem jedno, co všechno dalšího se na ty rituály navěsí, protože jejich podstata je pořád stejná. I když zrovna teď pro nás zima není takový problém. V jiných zeměpisných pásmech jsou důležité zase jiné jevy. Jistě, nemusíme tyhle rituály vázat na kalendář, ale pak už opravdu nemá smysl kalendář dělit na různě dlouhé roky a měsíce.

No a poledne je na tom podobně, rozděluje nám pracovní den na dvě části. Je tak nějak pohodlnější, když většina akcí trvá v čase od-do před polednem nebo v čase od-do po poledni, než když budou mít děti po škole kroužek od úterý 23:00 do středy 1:00. Ono se s tím přelomem dnů tak nějak hloupě pracuje, proto ho máme schovaný doprostřed noci (a umělé osvětlení v tom udělalo zmatek, takže teď bychom půlnoc potřebovali spíš mezi druhou a třetí, takže by pak mimo jiné přechod mezi standardním a letním časem vycházel logicky na půlnoc).

[Jendа]

(a umělé osvětlení v tom udělalo zmatek, takže teď bychom půlnoc potřebovali spíš mezi druhou a třetí, takže by pak mimo jiné přechod mezi standardním a letním časem vycházel logicky na půlnoc)

Vidíte, pár set let a už by byla potřeba změna oproti přesnému nebeskému kalendáři.

Půlnoc mezi druhou a třetí se udělá, když zrušíte přestupnou sekundu a počkáte 20000 let .

[Filip Jirsák]

Nemyslím si, že by byla potřeba změna, ty aktivity kolem půlnoci většinou už na počítání času moc nezávisí.

[Jendа]

Jistě, nemusíme tyhle rituály vázat na kalendář

Například Velikonoce již nejsou definovány na základě kalendáře. Je to první úplněk po rovnodennosti (která v Gregoriánském systému plave). Tak už stačí předefinovat Vánoce na zimní slunovrat a jste za vodou. To teda stejně budete muset udělat (nebo zadat nepravidelně přestupný den, čímž zničíte o jedno posunete počítání dní v týdnu, hodně štěstí :), protože in the year 12,000 the calendar would fall behind by at least 8 but less than 12 days..

[Filip Jirsák]

Psal jsem, že je správné teď řešit korekce těch odchylek, o kterých dobře víme. Odchylky, které odhadujeme s přesností plus minus autobus, bych teď nechal být. Ono je dobré mít trochu pokory vůči budoucím generacím, a řešit ty problémy, které vznikají teď a které umíme řešit, a nepokoušet se dopředu řešit něco, o čem vůbec netušíme, jak to dopadne. Není třeba si dávat tak ambiciózní cíle a plánovat čas na deset tisíc let dopředu, když ani ty přestupné sekundy nedokážeme naplánovat na déle než rok dopředu.

[Jendа]

Já nemluvil o plánování, já mluvil o přidání možnosti typu „z pravidla 4/100/400 se může nařídit výjimka“. Protože jeho absence způsobí přesně to, co říkáte - až to bude potřeba, systémy na to nebudou připraveny.

[Filip Jirsák]

Myslíte, že nebude stačit ta pravidla změnit třeba sto let předem?

[Jendа]

Myslíte, že nebude místo přestupné sekundy stačit změnit časové pásmo v roce 20000 a announcnout to o sto let předem?

[Filip Jirsák]

Technicky to stačí. Ovšem prakticky je mnohem lepší dělat průběžně malé korekce než jednou za čas velké. Stačí si porovnat, jak bezproblémové je řídit se gregoriánským kalendářem, a jak problémová byla jednorázová korekce na jeho začátku. Pokud je někde tisíce let systematická chyba, která postupně naroste až na jednu hodinu, jaký smysl má po deseti tisících let tu chybu korigovat?

[Jendа]

Pak by bylo nejlepší měnit délku sekundy. Počítače si s přepočty frekvenčních normálů jistě snadno poradí.

(Ne, opravdu, vy fakt čekáte, že za 50000 let (~10násobek prozatímního trvání civilizace měřící čas) se bude používat současný systém, ještě k tomu vázaný na Zemi? Jak se stavíte k níže předloženému výpočtu, že časem nebudou stačit ani povolené dvě přestupné sekundy ročně?)

[Atom321]

Ovšem prakticky je mnohem lepší dělat průběžně malé korekce než jednou za čas velké.

Praktické zkušenosti ukazují, že se mýlíte. Při změně pravidel letního času v USA v roce 2005 a jeho úplném zrušení v Ruské Federaci v r. 2011 žádné závažné problémy nenastaly. S přestupnou sekundou jsou v poslední době nějaké potíže pokaždé.

Stačí si porovnat, jak bezproblémové je řídit se gregoriánským kalendářem, a jak problémová byla jednorázová korekce na jeho začátku.

Ano, je bezproblémový, protože je předvídatelný, je snadný na pochopení a dá se snadno implementovat. Problémový byla korekca na začátku, protože to byla výjimečná situace. Přestupná sekunda přináší potíže, protože není snadno předvídatelná a je to de-facto výjimečná situace pokaždé.

Pokud je někde tisíce let systematická chyba, která postupně naroste až na jednu hodinu, jaký smysl má po deseti tisících let tu chybu korigovat?

Žádný! To je to, o čem se tu celou dobu bavíme. Systematickou odchylku, která plíživě naroste na jednu hodinu za pět tisíc let nemá smysl korigovat.

[Ondrej Santiago Zajicek]

Myslím, že s gregoriánskou korekcí juliánského kalendáře se lidé netrápili jen tak, že zrovna neměli do čeho píchnout

To bylo tehdy hlavne z nabozenskych duvodu (vazba nabozenskych svatku). Proto tu reformu take zavedl papez Gregor.

Jenže poptávka po tom opustit tenhle systém není velká.

Evidentne je, kdyz se o tom opakovane jedna na ITU konferencich.

[pavlix]

takže těžko najdete přesvědčivý důvod, proč to měnit.

Tak proč se to už tolikrát změnilo?

[Ivan]

Jen dodam, ze zemestreseni, ktere pred par lety postihle thajsko bylo tak silne, ze ovlivnilo i rychlost rotace Zeme. Tzn neni mozne dopredu predpovedet jak rychle se nase planeta bude tocit.

PS: I bez tech zemetreseni je to slozity. Muj spolubydlici na MFF mel jedno-semestralni predmet nazvany "Rotace zeme". Kdyz jsem se ptal co se tam cely semestr uci ze je to prece "jednoduchy" tak jsem dostal odpoved ze ktery jsem pochopil ze nemam na to abych to pochopil.

[Jendа]

Nebo ještě lépe: předpokládejme, že čas 30.6.2016 23:59:59 nebude existovat. Systém by se k němu měl chovat jako k jakémukoli jinému neexistujícímu času. Tvůj at démon sežere čas 32.13.2015 28:173:97?

[Ondrej Santiago Zajicek]

Protoze to neni jen 'sekunda navic', je to specialni pripad aktivovany synchronizovane jednou za par let.

[Atom321]

Ta sekunda samotná ne. Problémy zavádí porušení pravidla, že minuta má 60 sekund.

[Heron]

Odkdy je tohle pravidlem?

[venca]

Není.

Ve skutečnosti minuta je 60 vteřin.

Čas je třeba udávat vždy ve správném tvaru, např.:

5 minut, 16 vteřin a 39 setin sekundy.

[Pomi]

Vteřina je úhlová jednotka. Akčkoliv to mnoho lidí říká nesprávně, tak jednotkou času je sekunda.

[kamil]

To platilo za totality. Teď je to už 25 let jinak. Viz citace z článku:

Hranice, která teď odděluje nejrychlejšího muže světa od zbytku smrtelníků, je 9 vteřin a 58 setin sekundy.

[Erbureth]

Ano, protože v televizi se nikdy nevyjadřují špatně... </s>

[SPM]

Za totality právě platila ta vteřina, pak se přešlo na jednotky SI a je to sekunda...

[Filip Jirsák]

Nikoli, na SI se přešlo dřív. Za totality se rozhodlo, že i v obecné češtině se musí používat přesné termíny SI. Po pádu totalitního režimu jsme se vrátili k tomu, že obecná čeština není to, co někdo nadiktuje, ale to, jak lidé mluví. V současné době je tedy v obecné češtině správně sekunda i vteřina.

[květoslav]

Slovo vteřina vymyslel cca před 190 lety mnich, matematik a spisovatel Sedláček jako náhradu cizího slova sekunda.

Slovo vteřina se ujalo v hovorové češtině a současnosti je používáno v médiích, např. v souvislosti s měřením času ve sportu. Nicméně podle jednotek soustavy SI má být jednoznačně sekunda, což je i v souladu s čím dál hojnějším výskytem cizích slov v mluveném i psaném projevu.

[Filip Jirsák]

Já jsem ale nepsal o používání jednotek soustavy SI, ale o obecné češtině. A v obecné češtině je možné používat obojí, stejně jako se používá slovo váha místo přesného termínu hmotnost, nebo se jako jednotka tlaku používá bar.

[Ondrej Santiago Zajicek]

To, ze je to mozne tak delat, neznamena, ze to neni hloupe.

[radix]

Tak nam to rikali ve skole.

[Atom321]

Podle Wikipedie to vychází z Babylonské šedesátkové soustavy, kterou pak pro měření času použili Helénští astronomové. Název pochází z latinského "pars minuta secunda", tj. druhé zmenšené dělení.

V moderní době minutu, hodinu a den definuje od r. 1960 Mezinárodní soustava jednotek SI jako ne-SI jednotky povolené pro použití s jednotkami SI a to výslovně jako 60, 3600 a 86400 sekund.

[ne]

Se dívej na Branky, body vteřiny, když tam dávaj výsledky ňákejch běhů.

[Heron]

V moderní době minutu, hodinu a den definuje od r. 1960 Mezinárodní soustava jednotek SI jako ne-SI jednotky povolené pro použití s jednotkami SI a to výslovně jako 60, 3600 a 86400 sekund.

To ale vůbec nijak nesouvisí s problémem přestupné sekundy, to je prostě jen definice převodů mezi násobky, podobně jako definice k, M, G apod.

[Ondrej Santiago Zajicek]

To souvisi, napr. v tom, ze vymezeni casu jako '3 min po 2015-06-30 23:59:30' muze byt stejne tak 2015-07-01 00:02:30 jako 2015-07-01 00:02:29, a obe ty interpretace jsou korektni (akorat kazda podle jine interpretace minuty od jine mezinarodni organizace).

[Heron]

To je poněkud zváštní interpretace. 3 min podle SI lze převést na 180s. Toť vše. AFAIK (a nechám se klidně poučit), SI nijak nedefinujeme "běh času", takže 2015-06-30 23:59:30 + 3min (nebo 180s) se čistě v rámci SI nijak nedefinuje a je k tomu potřeba právě nějaké další definice běhu času a to se dostáváme k ruzným časovým soustavám (TAI, UTC apod.)

[Ondrej Santiago Zajicek]

Uvedu jiny priklad: 'fyzikalni jev trva presne 3 minuty. Fyzikalni jev zacal presne v 2015-06-30 23:59:30 UTC. Kdy fyzikalni jev skonci?' Prvni veta mluvi jen o relativnim casovem intervalu, ktery je definovan uz v ramci SI (a nepotrebuje casovou soustavu).

[Heron]

V čase dle UTC skončí 2015-07-01 00:02:29. Vybral jsem si UTC, protože jsi počátek jevu též definovat v UTC.

Kdyby to bylo TAI, tak by to bylo, tak by ten jev začal v 2015-07-01 00:00:34 TAI (pokud se úplně nepletu) a skončil potom 2015-07-01 00:03:34 TAI.

[Ondrej Santiago Zajicek]

V čase dle UTC skončí 2015-07-01 00:02:29. Vybral jsem si UTC, protože jsi počátek jevu též definovat v UTC.

Ano, protoze z formulace bylo jasne, ze ty tri minuty jsou ve smyslu 180 s. Ale napr formulace '2015-06-30 23:59:30 UTC + 3 min' uz muze byt interpretovana bud stejne nebo jako navyseni minutove slozky v UTC datu a tedy jako '2015-07-01 00:02:30 UTC'.

[Jendа]

Ale ty převody plavou! Někdy má den 86400, někdy 86401, někdy 86399 sekund. To je jak kdyby někdy měl kilometr 999 a někdy 1001 metrů a navíc ti nikdo nebyl schopen víc než půl roku dopředu říct, kolik to bude! Absurdní!

[Ondrej Santiago Zajicek]

Je to jeste absurdnejsi. Den podle ITU ma ruzny pocet sekund, den podle BIPM ma vzdy 86400 sekund. Oboje definice plati zaroven

Den 2015-06-30 tedy trva den a jednu sekundu.

[květoslav]

Den 2015-06-30 tedy trva den a jednu vteřinu.

[Heron]

Ne, ty převody neplavou. Den má 86400, hodina 3600, minuta 60 sekund. Den s přestupnou sekundou nemá 86401s, ale den+1s. Nevím, co je pořád za problém.

a navíc ti nikdo nebyl schopen víc než půl roku dopředu říct, kolik to bude!

Což plyne přímo z fyzikální podstaty problému. Až budeme schopni měřit a počítat s dostatečnou přesností všechny vlivy na rotaci Země, budou se dělat tabulky s přestupnými sekundami na 100 let dopředu. Zatím to nejde.

A kdo potřebuje, tak má k disposici hromadu dalších časových soustav kde se přestupná sekunda nevyskytuje.

[Jendа]

Den s přestupnou sekundou nemá 86401s, ale den+1s.

OK.

Což plyne přímo z fyzikální podstaty problému.

Já to chápu. A je mi jasné, že třeba astronomové, kteří si potřebují nastavit dalekohledy, nejspíš zvolí nějakou časovou soustavu, která odchylky v otáčení Země zohledňuje. O co mi celou dobu jde je to, že je takový systém krajně nevhodný pro neastronomické použití.

A kdo potřebuje, tak má k disposici hromadu dalších časových soustav kde se přestupná sekunda nevyskytuje.

Samozřejmě. A přepočítávat pokaždé když se bude bavit s někým okolo.

[Ondrej Santiago Zajicek]

Já to chápu. A je mi jasné, že třeba astronomové, kteří si potřebují nastavit dalekohledy,

Me neni jasne, zda to vubec potrebuji ti astronomove. Co jsem cetl, tak ti pouzivaji TT (terrestrial time, ktery ma fixni offset od TAI a tedy prestupne sekundy nepouziva) a k nemu tabulku efemeridu.

[Ondrej Santiago Zajicek]

Kdyby to nekoho zajimalo, tak tady je odkaz na web Mezinarodniho uradu pro miry a vahy. Ze ITU definuje minutu (v ramci UTC) v rozporu s definici minuty od BIPM neni zas tak prekvapive, kdyz si uvedomime, ze tu je jeste UT1 casovy standard, ktery je postaven na ~60 let mrtve definici sekundy a UTC se ten standard snazi aproximovat pomoci soucasne SI sekundy. IMHO je to marna snaha a snad jim to brzy dojde.

[Ondrej Santiago Zajicek]

AFAIK, u problemu v predchozich letech nehralo roli ani tak kolik sekund ma minuta, ale implementacni problemy spojene s existenci prestupne sekundy jako special case.

[luky]

A kde jste takove pravidlo videl? Vsude se pise, ze sekunda v minute nabyva hodnoty 0 - 60, SUSv2 dokonce rika 0 - 61. 0 - 59 jsem nikde nevidel.

Pokud nekdo necte dokumentaci a pak cumi jak puk, ze se neco chova, jak je napsano ve specifikaci, tak ma zpusobne mlcet a doma si sbicovat zada a ne se nad tim verejne rozhorcovat.

[Ondrej Santiago Zajicek]

ale realne problemy s prestupnou sekundou byly casto uplne nekde jinde, nez ze by napr. ve strukture tm ziskane pomoci ctime()/gmtime() z unix time. V praxi se tam ta 60 neobjevi ani behem prestupne sekundy (kvuli limitaci unix time).

[Atom321]

Zbičovat záda by si měli pitomci, co tuhle krávovinu zavedli, v rozporu s letitými zvyklostmi, zdravým rozumem i staršími normami. Nepřináší to vůbec nic užitečného, jen samé potíže.

[luky]

Jake zvyklosti? Bylo to zavedeno v roce 1972 a existuje to uz napr. v ANSI C, SRV3 atd. Jake starsi normy mate na mysli? Ty z doby pred rokem 1972, co nepouzivaly prestupnou sekundu, ale gumovou sekundu?

[Filip Jirsák]

Chápu to správně, že vy se dosud řídíte juliánským kalendářem? Protože vaše důvody platí úplně stejně i na gregoriánský kalendář. Akorát se s těmi přestupnými sekundami začalo včas, protože zkušenosti s přechodem na gregoriánský kalendář ukazují, že korigovat to teprve tehdy, až je ten časový posun znatelný, a to ještě v každé části světa jinak, není zrovna to nejlepší řešení.

[Ondrej Santiago Zajicek]

Zrovna problemy, ktere resi prestupna sekunda, by slo resit daleko snaz prostym posunem casovych zon o hodinu (jednou za par set let, az se ten rozdil naakumuluje na desitky minut) bez zasahu do referenciho casoveho standardu.

[Filip Jirsák]

Což by bylo podstatně horší řešení, než to s přestupnou sekundou. Špatné je kterékoli řešení, které provádí korekce pouze ve velkých časových rozestupech (takže v mezidobí se jejich možnost ignoruje, a když to nastane, jsou všichni překvapeni), a také kterékoli řešení, kdy časový posun člověk běžně pozná.

[Ondrej Santiago Zajicek]

Jenze zatimco prestupna sekunda se vklada primo do univerzalnoho referencniho casoveho standardu, posun casovych zon je obvykle jen veci prezentace. Koneckoncu v soucasnosti posouvame casove zony dvakrat rocne, kdyz prechazime z CET na CEST a zpatky a i nepravidelne zmeny casovych zon se deji daleko casteji nez jednou za par stoleti. Napriklad pred cca rokem presel Krym z EET na MSK.

[Jendа]

Musel bys změnit názvy časových zón, aby pak Central European Time nebyl na Sibiři . Na druhou stranu zpropagovat tuto změnu do všech systémů s dostatečným předstihem by neměl být problém, protože zatím se nastřádalo 25 sekund za 50 let. Hrubou extrapolací to tak dá hodinu za 7200 let.

[Ondrej Santiago Zajicek]

Hruba extrapolace je hrube spatne. Viz jeden muj starsi post:

Podle [1] je to zpomalovani v dlouhodobem prumeru linearni (a tedy akumulovana odchylka kvadraticka) a to s tempem prodlouzeni stredni delky dne o 1.7 ms za stoleti, z toho jsem vychazel. Je tam jeste nejaka dlouhodobe fluktuace s periodou cca 1500 let a amplitudou cca 4 ms/stoleti, ale ta ted naopak zacina zpomalovani snizovat, takze v neblizsich nekolika stoletich by to melo byt spis mene (odhadem 5 min za 500 let a 30 min za tisic let).

[1] F. R. Stephenson and L. V. Morrison: Long-Term Fluctuations in the Earth's Rotation: 700 BC to AD 1990

Ale take jsem videl jiny odhad, ktery uvadel snad hodinu za nekolik stovek let. Ale koneckoncu, pokud bude zpomalovani rotace takto rychle (akumulovana odchylka od dneska by byla vetsi nez hodinu za 1800 let), tak to drive nebo pozdeji stejne rozbije UTC, nebot by nestacily 2 prestupne sekundy za rok.

[Jendа]

Chápu to správně, že vy se dosud řídíte juliánským kalendářem? Protože vaše důvody platí úplně stejně i na gregoriánský kalendář.

Nevím, jak jeho, ale moje důvody na něj určitě neplatí. U gregoriánského kalendáře lze snadno spočítat, za jak dlouho bude 1.1.2040, protože pravidla o modulení 4, 100 a 400 jsou deterministická a předem daná. U přestupné sekundy ale nevíte, za jak dlouho bude 30.7.2016.

[Filip Jirsák]

Zvláštní je, že ty přestupné sekundy nikdy nikomu nevadily, až teď počítačům. Člověk by řekl, že počítače máme od toho, aby zvládly i komplikovanější situace, než jsme zvládali bez nich.

[Jendа]

Zvláštní je, že ty přestupné sekundy nikdy nikomu nevadily, až teď počítačům.

Jirsák, 1840: Zvláštní je, že ten bordel v lokálních časech nikomu nevadil, až teď vlakům.

Možná, že až do doby počítačů nedocházelo k masivní výměně informací obsahujících přesný čas mezi různými systémy, takže se prostě problém neprojevil.

[Heron]

Možná, že až do doby počítačů nedocházelo k masivní výměně informací obsahujících přesný čas mezi různými systémy, takže se prostě problém neprojevil.

Pokud bych chtěl být nepatrně jízlivý, tak ono je to spíše tím, kolik lidí se v roce 2014 diví (a to dokonce i z IT), že vůbec něco jako přestupná sekunda existuje (přitom je to jev starší než většina takto se divících). Vzhledem k tomu, že mám docela přehled o tom, kdo některé systémy vyměňujích si informace píše, tak se ani nedivím tomu, jaké problémy to v praxi způsobuje. A to za stavu, kdy existují kompletní knihovny schopné si poradit s převody mezi časovými soustavami a implementující celou časovou algebru. I přesto se donekonečna objevují implementace obsahující kód jako hour*3600+min*60+sec udělej něco.

[Jendа]

A to za stavu, kdy existují kompletní knihovny schopné si poradit s převody mezi časovými soustavami a implementující celou časovou algebru.

Pokud taková knihovna pro cílovou architekturu existuje, nezaplácne 80 % paměti daného mikrokontroléru a do zařízení se pravidelně dostávají informace o nově vyhlašovaných přestupných sekundách.

[Atom321]

Ano, moje důvody částečně platí i na Gregoriánský kalendář. Dnes by bylo 27. prosince, s čímž bych neměl nijak zásadní problém.

Gregoriánský kalendář zavedla Katolická církev v 16. století, protože měla potíže s určením první neděle po prvním jarním úplňku. Potíže se zaváděním byly minimální - změnila se pravidla pro přestupné dny a jednorázově se Vánoce vyhlásily o 10 dní dřív. Další rok po zavedení nebyl žádný problém. Oba kalendáře fungovaly další čtyři století paralelně (Pravoslavné asi termín Velikonoc tolik netrápil).

Přestupná sekunda, narozdíl od přestupného roku, je zaváděná nepravidelně a nelze ji určit předem nezávisle na zbytku světa. Není možné postavit hodiny, které budou za 10 let ukazovat přesný čas v UTC bez synchronizace s názorem hochů z IERS. Ani po 40 letech od zavedení není ve spoustě systémů správně implementována a působí potíže. Náklady na tento nesmysl jsou nesrovnatelně větší než všechny přínosy.

Juliánský kalendář posouvá začátek roku o 10 dní za 1000 let. Odchylka astronomického dne od atomových hodin zkrátí tisíciletí o zhruba 10 minut. Zvlášť vtipné mi přijde zavádět složitý mechanismus na kompenzaci jedné minuty za století a přitom dvakrát ročně šoupat čas o celou hodinu.

[Filip Jirsák]

Přestupná sekunda, narozdíl od přestupného roku, je zaváděná nepravidelně a nelze ji určit předem nezávisle na zbytku světa. Není možné postavit hodiny, které budou za 10 let ukazovat přesný čas v UTC bez synchronizace s názorem hochů z IERS.

Vadí to někomu, kromě teoretiků v diskusích?

Ani po 40 letech od zavedení není ve spoustě systémů správně implementována a působí potíže.

Přičemž se to týká téměř výhradně systémů, které jsou mladší než těch čtyřicet let. Takže je to jednoznačně chyba těch systémů. Spousta systémů také nebyla připravena na rok 2000 - měli jsme tedy mít podruhé rok 1900?

dvakrát ročně šoupat čas o celou hodinu

Nic takového se neděje. Pouze se mění časové pásmo, které se běžně používá v občanském životě. Nic vám nebrání měřit si čas v UTC, nebo třeba pořád v SELČ.

[Jendа]

Vadí to někomu, kromě teoretiků v diskusích?

Vadí to všem, kteří mají validovat vstup. Co váš program udělá, když mu pošlu jako vstup 30.6.2016 23:59:59?

Takže je to jednoznačně chyba těch systémů.

Když to má něco špatně fakt hodně lidí, možná by se stálo za to zamyslet se, jestli není problém například v příliš komplikovaném nebo nejasném standardu (neříkám, že je to tento případ).

Nic takového se neděje. Pouze se mění časové pásmo, které se běžně používá v občanském životě. Nic vám nebrání měřit si čas v UTC, nebo třeba pořád v SELČ.

Co kdybyste si tedy někdy kolem roku 10000 až se z přestupných sekund nastřádá hodina prostě posunul časové pásmo o jedno na východ?

Další možnost je prohlásit, že za 8000 let (což je víc než doba po kterou lidstvo vůbec používá systém dělení dne na hodiny) si lidi zvyknou, že Slunce nad hlavou nemají mezi 11. a 15. hodinou, ale mezi 12. a 16. Nebo že se do té doby lidstvo konečně dostane k osídlení jiných planet a systém založený na otáčení Země bude k ničemu.

[Heron]

Když to má něco špatně fakt hodně lidí, možná by se stálo za to zamyslet se, jestli není problém například v příliš komplikovaném nebo nejasném standardu (neříkám, že je to tento případ).

Problém s pochopením věci (resp. nevědomím že něco takového existuje), se vyskytuje snad u každého standardu nebo u každé problematiky. A je úplně jedno, jestli se to týká času, systémů souborů nebo třeba silové elektřiny. Pokaždé se najdou lidé, pro které je nějaký aspekt překvapivý a snaží se argumentovat "zdravým rozumem", zvyklostmi apod. Každá diskuse vypadá jak přes kopírák ať už se to týká čehokoliv. Evidentně je problém jinde než v oněch standardech.

[Jendа]

U Národního divadla je křižovatka, kde je cedule přikázaný směr jízdy doprava a potom je semafor, na kterém svítí trvale červená a občas se k ní rozsvěcí šipka doprava (přesně jako na tom Seznam Streetview). Velmi často se stane, že někdo přehlídne ten přikázaný směr a potom stojí na semaforu a čeká na zelenou rovně dokud ho někdo nevyzvoní nebo dokonce ten za ním nevyleze a nevysvětlí mu to.

Pokaždé když jedu do školy a vidím tam někoho takhle zaseknutého přemýšlím, kde se stala chyba. Jistě, on přehlédl či špatně interpretoval dopravní značení, které je de-iure správně. Když se to tam ale děje furt, nestálo by za to upravit „strandard“ (dopravní značení v tom místě), aby bylo srozumitelnější? Nebo to tak necháme a budeme se furt divit, proč to těm hloupým lidem nedochází?

[Heron]

nestálo by za to upravit „strandard“ (dopravní značení v tom místě)

Dopravní značení na konkrétním místě bych nenazýval slovem standard ale implementací daného standardu. Implementace může být dobrá nebo špatná. V tomto konkrétním případě je implementace dopravního značení sice v pořádku z hlediska zákona, ale je naprostvo hrozná pro užívání. Zákon (nebo standard) nemůže pamatovat na všechna zvěrstva co si kdo v praxi vymyslí. (Prasit se dá v každém jazyce, to o jazyku nic nevypovídá.)

[Jendа]

Dopravní značení na konkrétním místě bych nenazýval slovem standard ale implementací daného standardu.

Ne, dopravní značení je standard a implementací je zachování se řidiče

V tomto konkrétním případě je implementace dopravního značení sice v pořádku z hlediska zákona, ale je naprostvo hrozná pro užívání.

No a já tvrdím, že přestupná sekunda i kdyby byla v pořádku by byla naprosto hrozná pro užívání.

[Heron]

Ne, dopravní značení je standard a implementací je zachování se řidiče

Ufff. Takže když někdo napíše implementaci algoritmu quicksort v jazyce E (verze 2015) tak nepíše implementaci ale píše standard? A implementace je až to jak ta data protékají tím algoritmem? To jako vážně?

No a já tvrdím, že přestupná sekunda i kdyby byla v pořádku by byla naprosto hrozná pro užívání.

No tak si vyber časový standard který ji neobsahuje.

[Jendа]

Dobře, necháme těch analogií, asi mám nekompatibilní myšlenkové pochody .

No tak si vyber časový standard který ji neobsahuje.

Už jsem psal že to nejde když zbytek světa zůstane v defaultu, protože to neřeší (a pak crashují počítače, padají letadla a bouchají solární elektrárny).

[pavlix]

U Národního divadla je křižovatka, kde je cedule přikázaný směr jízdy doprava a potom je semafor

Jsou chvíle, kdy bych znovu zavedl trest smrti. Nebo alespoň povinnou kastraci. Mimochodem u nás posrali značení taky dokonale. Při výjezdu od nás je omylem zákaz odbočení vlevo, přitom je to zjevná výjezdová cesta. A dost dlouho zapomněli vyznačit jednosměrku v místě, kde byla vždy, ale nebyla značená, protože tam nebyl příjezd, který po mnoha letech obnovili. Dopravní značení má být pro všechny lidi, kteří řídí auto a podle toho by mělo vypadat.

[Ondrej Santiago Zajicek]

Problém s pochopením věci (resp. nevědomím že něco takového existuje), se vyskytuje snad u každého standardu nebo u každé problematiky.

Tady nejde o neznalost ci nepochopeni veci, ale spis o to, ze to byl pitomy napad od zacatku a stavajici zkusenosti pro to jen dodavaji argumenty.

[pavlix]

+1

[Jendа]

Vadí to všem, kteří mají validovat vstup. Co váš program udělá, když mu pošlu jako vstup 30.6.2016 23:59:59?

Můžete ho odmítnout, ale předpokládám, že ho přijmete a data uložíte. Za rok je vezmete z disku a zjistíte, že takový čas nebude existovat. Řeknete, že tím uživatel ve skutečnosti myslel 1.7. 0:00:00, ne, počkat, radši ne, to už je z dalšího měsíčního zúčtovacího období a zákazník by byl jistě nerad, abychom mu strhli další měsíční platbu, když chtěl službu 30.6. ukončit. Tak to bude 30.6. 23:59:58, ta sekunda v intervalu blbě nikoho nezabije. Ale radši nevydávejte standard, že se to v těchto situacích vždycky posunuje o sekundu dozadu, protože někdo určitě vymyslí corner-case, kdy to nejde. Ale taky doufejte, že to tak všechny systémy, se kterými komunikujete, implementují, i když to nebude ve standardu, protože jinak vyrobíte race condition. Jo a mimochodem musíte nějak zajistit, aby se všichni na celém světě o přestupné sekundě dozvěděli atomicky.

[Heron]

Mě fascinuje, kolik událostí se plánuje zrovna zcela přesně na 23:59:59

V reálných systémech je to spíše definováno jako "platnost do konce měsíce června", nebo platnost v měsících leden, únor. To, kdy přesně končí únor (je přestupný rok?) je při takovém zadání docela jedno. A pokud to není jedno, tak až skončí, lze spočítat jeho délku přesně na sekundy, pokud je to nutné. A pokud je to nutné vědět dopředu, je možné použít soustavu, ve které tento problém vůbec neexistuje.

Nemohu si pomoct, ale pořád vidím problém na straně návrhu systému, kterému něco takového může způsobit problém a nikoliv problém v časovém standardu samotném.

[Jendа]

Mě fascinuje, kolik událostí se plánuje zrovna zcela přesně na 23:59:59

Vypadá to tak. Posledně nějaké sytémy crashly, a to dokonce ani nebyla ta sekunda vypuštěná.

Jde spíš o to, že máš systém, do kterého ti nedůvěryhodní uživatelé a ostatní systémy můžou posílat nějaké záznamy, které obsahují timestamp se sekundovou přesností. To už je snad běžnější případ, ne?

[Heron]

Jde spíš o to, že máš systém, do kterého ti nedůvěryhodní uživatelé a ostatní systémy můžou posílat nějaké záznamy, které obsahují timestamp se sekundovou přesností. To už je snad běžnější případ, ne?

No je a co? Tak ty údaje zvaliduju tak jak nejlépe umím a pokud v průběhu času zjistím, že je nějaký údaj nevalidní (například tím, že bude vyjmuta jedna sekunda), tak se podle toho nějak zachovám. To chování při této situaci už bude definované v návrhu onoho systému.

V této chvíli už mi tato diskuse fakt přijde absurdní a už se točíme v kruhu. Přestupná sekunda se vyhlašuje dost dlouho dopředu na to, aby se stihlo dané systémy jednak otestovat (pokud nějakou chybou na to nebyly testovány) a také aktualizovat. Úplně stejně, jak se xkrát do roka aktualizují tabulky timezones. Zajímavé je, že když se několikrát za rok aktualizuje balít tzdata (+ tzdata-java) tak to nikomu nevadí, ale když se půl roku dopředu ohlásí úprava o sekundu, tak je to najednou neřešitelný problém. Způsoby, jak tento "problém" řešit jsou známé a už i v této diskusi byly několikrát zmiňovány.

[Jendа]

To chování při této situaci už bude definované v návrhu onoho systému.

Jenže svět není jen tvůj systém.

aby se stihlo dané systémy jednak otestovat

Ale na co je chceš testovat, když přestupnou sekundou vznikne standardem nedefinované chování?

Zajímavé je, že když se několikrát za rok aktualizuje balít tzdata (+ tzdata-java) tak to nikomu nevadí

Možná proto, že přepočet na časové zóny je na rozdíl od přestupné sekundy jednoznačný.

Způsoby, jak tento "problém" řešit jsou známé a už i v této diskusi byly několikrát zmiňovány.

Stále jsi mi neřekl, co mám udělat, když jsem vývojář databáze a najednou zjistím, že ve sloupečku s typem DATETIME mám neexistující čas.

[Heron]

Ale na co je chceš testovat, když přestupnou sekundou vznikne standardem nedefinované chování?

Standardem nedefinované? On nějaký standard popisuje celý tvůj program? Program někdo navrhl a ten měl tento případ ošetřit. Pokud neošetřil, postupuje se stejně jako při nálezu jakékoliv jiné chyby v programu.

Stále jsi mi neřekl, co mám udělat, když jsem vývojář databáze a najednou zjistím, že ve sloupečku s typem DATETIME mám neexistující čas.

Mám pocit že řekl a to hned několikrát. Například tady #57

[Jendа]

Standardem nedefinované? On nějaký standard popisuje celý tvůj program?

Ne, ale čekal bych, že když se ve standardu napíše, že se může zrušit únor, že se tam taky nějak vyřeší, co třeba dělat se smlouvami, na kterých je napsáno, že platí do února.

Program někdo navrhl a ten měl tento případ ošetřit.

Problém není v tom, že by to neošetřil, ale v tom, že to každý ošetří jinak. Někdo to posune na první sekundu následujícího dne, někdo na poslední sekundu dne, ke kterému to patřilo.

Mám pocit že řekl a to hned několikrát. Například tady #57

Mám pocit, že jsem v #76 napsal, proč je převod na následující den špatně. Namátkou u UPC nebo u T-Mobile se platí za načaté zúčtovací období jako za celé.

[Heron]

Mám pocit, že jsem v #76 napsal, proč je převod na následující den špatně.

V komentáři 57 uvádím i další řešení a jistě existují i další (zmíněná v jiných komentářích), než jen posun na následující časový bod.

[Jendа]

V komentáři 57 uvádím i další řešení

Zeptat se uživatele mi přijde jako jediné správné řešení. Bohužel to znamená další otravnou hlášku, řešit, jestli na něj vlastně mám kontakt, a co dělat, když neodpoví. A taky všechno tohle implementovat…

[Heron]

Tak ono konkrétní řešení záleží na konkrétní situaci. Od včerejška marně přemýšlím nad reálným případem, kdy by skutečně záleželo na jedné sekundě a to navíc ještě o půlnoci. Na nic reálného jsem nepřišel a většina věcí typu konce fakturačního období se dá docela dobře řešit zcela automaticky.

Ano, můžeme argumentovat já nevím například daty ze senzorů z nějakého průmyslového zařízení, ale pro tento případ mi nepřipadá vhodné používat UTC, ale spíše nějaký monotónní čas. Klidně pro každou fabriku jiný. Dělá se to tak. A zpětně není problém tento čas převést na UTC, pokud by to bylo potřeba (rafinerie explodovala 15:30:46 a senzory hlásili chybu v čase 123456789s od počátku, což odpovídá 15:30:46).

Já v tom prostě nevidím problém.

[Jendа]

Souhlasím, že v praxi se třeba u té expirace účtu ta sekunda sem tam nějak vyřeší, a v této „první iteraci vývoje“ problém nejspíš nebude. Jenže časem se ten systém bude různě měnit, knihovny se budou používat znova jinde, a pak najednou spadne kernel jako při poslední přestupné sekundě - čekal bych, že tam ten problém vznikl nějak takhle.

[Filip Jirsák]

Zrovna v případě expirace účtu je velice nepravděpodobné, že by expiroval zrovna ve 23:59:59. Daleko pravděpodobnější je, že expiruje půlnocí, tedy že bude platný do libovolného času před půlnocí, a okamžikem půlnoci přestane být platný. Expirace na 23:59:59 vyjde jedině tehdy, pokud se bude počítat přesně od času registrace a někomu se podaří účet založit přesně v tuto vteřinu. Jenže pak řešíte úplně stejný problém, jako když si někdo zaregistruje 29. února 2016 účet na rok, nebo když si 31.5.2016 zaregistruje účet na měsíc.

[pavlix]

Zrovna v případě expirace účtu je velice nepravděpodobné, že by expiroval zrovna ve 23:59:59.

To zní jako obhajoba tvorby občas se vyskytujících chyb.

[Filip Jirsák]

Bývá dobré přečíst z komentáře více než jednu větu.

[Ondrej Santiago Zajicek]

to navíc ještě o půlnoci.

Vzhledem k tomu, ze jde o pulnoc UTC, tak to muze byt v libovolne hodine podle prislusneho lokalniho casu.

[Filip Jirsák]

Řešíte tu teoretické problémy. Do jakého programu budete dnes zadávat vstup 30.6.2016 23:59:59? Navíc pokud by se někam zadával takovýto vstup, nejspíš se zadává špatně. Protože buď na tenhle čas vyjde konec nějakého intervalu určeného délkou, pak si ale máte zapamatovat ty vstupní údaje, tedy počáteční čas a délku intervalu. Nebo to ve skutečnosti má znamenat otevřený konec intervalu 1. 7. 2016 0:00:00, pak si zase máte uložit tenhle údaj. Protože co když si pak někdo vzpomene, že to musí být s přesností na setiny sekundy, a vy budete mít chybně uloženo 23:59:59,00 místo 23:59:59,99.

Problém s přestupnou sekundou nemá fakt hodně lidí, jenom pár programátorů. No a když se to zvládalo desítky let bez počítačů, tak by to počítače také mohly zvládnout, ne?

Posouvat něco za 8000 let nemá vůbec žádný smysl, protože lidé by si buď dávno zvykli, a ten posun by byl nesmyslný, nebo by si ten posun udělali už mnohem dřív po svém (nejspíš tak, že by si jednotlivé státy migrovaly mezi časovými pásmy podle svého, takže byste jel z Francie přes Německo a ČR na Slovensko, a třikrát byste měnil časové pásmo). Přínos toho současného řešení je právě v tom, že se ta korekce dělá průběžně po tak malých dílcích, že si toho nikdo nevšimne. Podle mne vůbec nejde o to, aby lidé měli v poledne Slunce nad hlavou, ale právě o to, aby ty korekce byly co nejmenší.

[Jendа]

Do jakého programu budete dnes zadávat vstup 30.6.2016 23:59:59?

Třeba do vašeho webového prohlížeče.

Set-Cookie: foo=bar; Domain=abclinuxu.cz; Path=/; Expires=Thu, 30 Jun 2016 23:59:59 GMT

Navíc pokud by se někam zadával takovýto vstup, nejspíš se zadává špatně. Protože buď na tenhle čas vyjde konec nějakého intervalu určeného délkou, pak si ale máte zapamatovat ty vstupní údaje, tedy počáteční čas a délku intervalu. Nebo to ve skutečnosti má znamenat otevřený konec intervalu 1. 7. 2016 0:00:00, pak si zase máte uložit tenhle údaj. Protože co když si pak někdo vzpomene, že to musí být s přesností na setiny sekundy, a vy budete mít chybně uloženo 23:59:59,00 místo 23:59:59,99.

HTTP a SMTP to dělají blbě, jenom já jsem letadlo. A co vaše databáze, ta by také neměla umožňovat uložení typu DATETIME?

pak si ale máte zapamatovat ty vstupní údaje, tedy počáteční čas a délku intervalu

To vypadá že problém nevyřešilo, jenom místo toho, co znamená

<expires>2016-06-30 23:59:59</expires>

budete zkoumat, co znamená

<start>2016-06-30 23:59:59</start>
<durationMonths>12</durationMonths>

No a když se to zvládalo desítky let bez počítačů, tak by to počítače také mohly zvládnout, ne?

Jasně, a když se zvládala plaintextová komunikace a nešifrované telefonování desítky let bez počítačů, tak SSH, TLS a A5/3 taky nejsou potřeba.

Posouvat něco za 8000 let nemá vůbec žádný smysl, protože lidé by si buď dávno zvykli, a ten posun by byl nesmyslný, nebo by si ten posun udělali už mnohem dřív po svém

Jako že by si ČR za 100 let posunula čas o minutu dozadu. Jen tak pro nic za nic (pozn. rozdíl mezi Aší a Ostravou je pokud dobře počítám 24 minut).

Podle mne vůbec nejde o to, aby lidé měli v poledne Slunce nad hlavou, ale právě o to, aby ty korekce byly co nejmenší.

Pokud vás nezajímá Slunce nad hlavou (asi ne, jinak byste mnohem dřív než přestupnou sekundu začal řešit časová pásma), proč tedy vůbec řešíte nějaké korekce?

[Filip Jirsák]

Set-Cookie: foo=bar; Domain=abclinuxu.cz; Path=/; Expires=Thu, 30 Jun 2016 23:59:59 GMT

No a co? Vadí to něčemu? Co když tam bude Expires=Thu, 30 Jun 2016 25:59:59 GMT?

A co vaše databáze, ta by také neměla umožňovat uložení typu DATETIME?

Já jsem nepsal, že by někde neměla být možnost uložení typu datetime. On ten typ totiž s přestupnou sekundou nemá vůbec žádný problém.

To vypadá že problém nevyřešilo, jenom místo toho, co znamená

<expires>2016-06-30 23:59:59</expires>

budete zkoumat, co znamená

<start>2016-06-30 23:59:59</start>
<durationMonths>12</durationMonths>

Vzhledem k tomu, že to budu řešit krátce před 30.6.2017, kdy už o případné přestupné sekundě vím, není to žádný problém.

Pokud vás nezajímá Slunce nad hlavou (asi ne, jinak byste mnohem dřív než přestupnou sekundu začal řešit časová pásma), proč tedy vůbec řešíte nějaké korekce?

Protože používáme čas vázaný na vzájemné postavení Země a Slunce, které ovlivňuje spoustu pro nás významných jevů na Zemi. Kdybychom tuhle vazbu nechtěli, můžeme zrušit přestupné roky, roky vůbec, měsíce a dny, a budeme počítat třeba počet sekund od 1. 1. 2000 0:00:00 UTC. Jenže většina lidí chce používat ten čas vázaný na přírodní jevy, a pak nedává smysl mít to navázané nepřesně - přijdete o výhody a zůstanou jen nevýhody.

[Jendа]

No a co? Vadí to něčemu? Co když tam bude Expires=Thu, 30 Jun 2016 25:59:59 GMT?

Tipuju, že by to váš prohlížeč měl odmítnout. Nebo si má vymyslet, že tím autor myslel 1.7. 0:59:59?

On ten typ totiž s přestupnou sekundou nemá vůbec žádný problém.

Nemá řešit, když do něj dám neexistující čas?

Vzhledem k tomu, že to budu řešit krátce před 30.6.2017, kdy už o případné přestupné sekundě vím, není to žádný problém.

Ale zjistíte, že ten čas uvedený ve <start/> neexistoval. Naúčtujete mu červen 2016 a červenec 2017?

Jenže většina lidí chce používat ten čas vázaný na přírodní jevy, a pak nedává smysl mít to navázané nepřesně - přijdete o výhody a zůstanou jen nevýhody.

Takže ještě jednou: máte nějaký návrh, co udělat s kvantizovanými časovými pásmy, nekruhovou dráhou Země a letním časem, které vnáší o řád větší nepřesnosti než jev, který se snaží řešit přestupná sekunda? Budou různě dlouhé dny v roce a bude v Brně o 8 minut víc než v Praze?

[Filip Jirsák]

Tipuju, že by to váš prohlížeč měl odmítnout. Nebo si má vymyslet, že tím autor myslel 1.7. 0:59:59?

Jak to prohlížeč odmítne? Pošle serveru ten požadavek ještě jednou s nějakou sprostou hlavičkou? Nebo odmítne stránku zobrazit? Já myslím, že existuje několik dobrých řešení, co s tím prohlížeč může udělat, jedno řešení nastaví expiraci cookies do konce session, ostatní řešení nastaví expiraci na různé časy 30.6.2016 nebo 1.7.2016.

Nemá řešit, když do něj dám neexistující čas?

Může a nemusí to řešit.

Ale zjistíte, že ten čas uvedený ve <start/> neexistoval. Naúčtujete mu červen 2016 a červenec 2017?

Nezjistím. Pokud ten čas neexistoval, nešel takový údaj zadat. Pokud někdo 1.7.2016 nebo později zadá 30.6.2016 23:59:59, tak ten čas buď existoval, nebo ten čas odmítnu jako neplatný. Přestupné sekundy se nikdy nepřidávají ani neubírají zpětně.

Takže ještě jednou: máte nějaký návrh, co udělat s kvantizovanými časovými pásmy, nekruhovou dráhou Země a letním časem, které vnáší o řád větší nepřesnosti než jev, který se snaží řešit přestupná sekunda? Budou různě dlouhé dny v roce a bude v Brně o 8 minut víc než v Praze?

Ano, mám. Používat gregoriánský kalendář, časová pásma, letní čas a korekce pomocí přestupných sekund. Tím zajistíme, že náš občanský čas zůstane dlouhodobě (podle našich současných znalostí trvale) spojený s odpovídajícími přírodními jevy. Nepřesnosti tedy budou oscilovat kolem nějakého středu, občanský čas nebude systematicky ujíždět jedním směrem.

[Jendа]

Jak to prohlížeč odmítne?

Předpokládám, že cookie nenastaví. Nebo zahodí celou odpověď a zobrazí chybovou hlášku (jako když mu pošlete nevalidní X(HT)ML). To jste tu mám pocit dokonce vy kdysi obhajoval (nebo to byl Michal Kubeček?).

Nezjistím. Pokud ten čas neexistoval, nešel takový údaj zadat.

Ale on tam ten časový údaj zadal ještě před tím, než se vyhlásilo, že nebude existovat.

[Filip Jirsák]

Ale on tam ten časový údaj zadal ještě před tím, než se vyhlásilo, že nebude existovat.

Pak ho program nemá nutit zadávat nesmyslné údaje, a má mu povolit zadat skutečné údaje, kterými se to řídí. Například že první zúčtovací období začíná 1. 7. 2014 v 0:00:00 a zúčtovací období trvá jeden rok.

[Ondrej Santiago Zajicek]

Vadí to někomu, kromě teoretiků v diskusích?

Vzhledem k tomu, ze ITU se vazne uvazuje o zruseni prestupne sekundy a bude se o tom jednat na letosni World Radiocommunication Conference, tak zrejme ano.

[Ivan]

Potíže se zaváděním byly minimální

Potize se zavedenim nebyly vubec minimalni. Lidi se bourili, protoze verili, ze se jim zkrati zivot o ty dny, ktere byly vystrtnuty z kalendare. Nevic se k tomu nepridali vsichni a nasledky te nekopatibility vidime jeste dnes.

[Jendа]

Problémy zavádí především to, že čas není monotónní, spojitý, že lze přičítat do budoucnosti a že přepočet z unixového timestampu bude na všech systémech konzistentní.

[Jendа]

Reálný příklad, který jsem implementoval: Bereš hodiny z navigačního systému s PPS, který funguje tak, že ti nejdřív zatáhne za PPS a až potom ti pošle po sériáku NMEA zprávu obsahující čas, který platil v okamžiku náběžné hrany PPS. Bohužel s timestampem musíš pracovat i mezi PPS impulzem a tou zprávou po sériáku. Nemáš tak žádnou možnost zjistit, že k přestupné sekundě dojde, až ex post použiješ jeden timestamp dvakrát (alternativně můžeš zavést do protokolu speciální flag/zprávu, že jsme právě prošvihli přestupnou sekundu, a systémy za tím se podle toho musí umět korigovat).

Dle mého názoru je to zbytečné zesložitění, které za tu korekci vycházející na pár minut za tisíc let nestojí.

Čas by měl být monotónní a deterministický (kvůli přestupným sekundám nemůžeš říct kolik hodin bude za rok, protože někdo možná mezitím vloží přestupnou sekundu!). Vykašlete se na UTC a vyberte si časový standard, který přestupnými sekundami netrpí.

[Heron]

Čas by měl být monotónní a deterministický

Tak co ti brání si vybrat takovou časovou soustavu, která tohle splňuje? Na světě není jen UTC, naopak, každý obor, který to potřebuje, má svůj vlastní čas. Občanský čas je z různých důvodů v UTC.

[Jendа]

Tak co ti brání si vybrat takovou časovou soustavu, která tohle splňuje?

Okolí, které zůstalo u defaultu.

[Ivan]

Treba v takovy Etiopii ma den jen 12 hodin. Cas se meri od 6:00 AM to 6:00 PM. Kdyz zapadne slunce tak cas neplyne(neexistuje) a neni potreba se nijak vzrusovat.

Kdyz se nad tim zamyslite tak to ma neco do sebe.

[S.]

Pak je ale chyba na straně přijímače nebo možná protokolu NMEA, že Vám nedává informací o přestupných sekundách. Neznám navigační systém (pracuju s GPS, GLONASS, GALILEO, SBAS a velmi brzo i s BEIDOU), který by v navigačních zprávách nevysílal aktuální odchylku systémového času od UTC vlivem přestupných sekund a zároveň jakési datum a velikost příští změny.

[Jendа]

Pak je ale chyba na straně přijímače nebo možná protokolu NMEA, že Vám nedává informací o přestupných sekundách.

Samozřejmě. V GPS almanachu se tyto informace vysílají. Jen ten přijímač je neumí správně posílat.

A nebo se na to taky můžete dívat tak, že je chyba ve standardu, protože je zbytečně komplikovaný a pak to vede k takovýmto chybám.

[S.]

Tomu nějak nerozumím. Jak může nastat situace, že přijímač vypíše změřenou odchylku 1PPS, když nemá k dispozici UTC parametry, a tedy ani údaje o přestupných sekundách, ať už současných nebo plánovaných? Jak potom spočítá odchylku hodin družice od systémového času a následně odchylku 1PPS přijímače od UTC? Jak může vypisovat aktuální čas, když nemá data pro přepočet na UTC

Není mi jasné, jaký standard máte na mysli. NMEA? A neumí ten přijímač nějaký jiný protokol, třeba binární, kde se ty informace posílají?

Přestupná sekunda je v mnoha oblastech problém. Proto např. navigační systémy pracují s vlastním systémovým časem a přestupné sekundy nevkládají. Informace o nich ale mají k dispozici a družice je vysílají. Přestupná sekunda se avizuje cca půl roku dopředu, aby o tom přijímač nevěděl, to by musel být zapnutý těsně před vkládáním.

Tenhle Váš konkrétní příklad názorně ilustruje jednu velkou kategorii problémů, jenže ne s přestupnou sekundou jako takovou, ale se zařízeními (Váš konkrétní přijímač - mimochodem o jaký se jedná, není-li to tajné?), případně software nebo lidmi (nemyslím Vás), kteří s ní jednoduše neumí pracovat.

[Jendа]

Tomu nějak nerozumím. Jak může nastat situace, že přijímač vypíše změřenou odchylku 1PPS, když nemá k dispozici UTC parametry, a tedy ani údaje o přestupných sekundách, ať už současných nebo plánovaných?

Přijímač je má, ale neposílá je ven (minimálně po periodických NMEA, možná by z něj šlo vyrazit almanach a přečíst si to v něm). O přestupné sekundě to jestli jsem pochopil manuál vypadá takhle:

[PPS pulz]
NMEA bla bla předchozí pulz oznamoval 23:59:59
[PPS pulz]
NMEA bla bla předchozí pulz oznamoval 23:59:60 (ale vy jste si určitě mysleli, že to bylo 00:00:00, chá-chá)
[PPS pulz]
NMEA bla bla předchozí pulz oznamoval 00:00:00

Není mi jasné, jaký standard máte na mysli. NMEA?

Ne, UTC.

Váš konkrétní přijímač - mimochodem o jaký se jedná, není-li to tajné?

Hledal jsem to a už si to nepamatuju, taková plechová kostka od Trimblu s L1 i L2 a dali mi k tomu takovou nic moc dokumentaci (možná výrobce dodává lepší, možná jenom pod NDA, těžko říct). Já jsem dělal jenom zařízení, co tu NMEu četlo a ovládalo podle toho lidar a kameru.

ale se zařízeními, případně software nebo lidmi, kteří s ní jednoduše neumí pracovat

A nebo to taky ukazuje na to, že standard obsahuje dle mého názoru málo užitečné věci, jejichž implementace je komplikovaná a snadno se v ní udělá chyba.

[S.]

Ten výpis je ale v pořádku, žádnou chybu tam nevidím. Přijímač vypisuje čas UTC a údaj 23:59:60 je OK. To ten další SW měl rozpoznat, že se jedná o přestupnou sekundu.

S Trimblem jsem nikdy nepracoval.

Implementace může být složitá, ale je velmi dobře (ehm, složitě) popsaná v dokumentaci GPS, konkrétně např. v ICD-GPS-200C, Revision IRN-200C-004 April 12, 2000. Je tu ještě takový malý detail – jedná se o přepočet času GPS na UTC(USNO). Pak si ještě musíte z Mezinárodního úřadu pro míry a váhy (BIPM) každý měsíc stáhnout Cirkulář-T, kde se dozvíte odchylku UTC(USNO) od UTC. Tedy pokud Vás těch ±5 ns vytrhne.

[Jendа]

Ten výpis je ale v pořádku, žádnou chybu tam nevidím.

V okamžiku mezi

[PPS pulz]

a

NMEA bla bla předchozí pulz oznamoval 23:59:60

nevíš kolik je hodin (protože v normální dny je 00:00:00, v přestupný den je 23:59:60, ale ty nevíš, jestli je přestupný den). A vzhledem k tomu, že podstata zařízení byla když mu přijde další pulz přiřadit k němu přesný (milisekundový) timestamp, tak to je docela problém.

[S.]

Samozřejmě, že mezi PPS a NMEA zprávou nemáte informaci o čase. To si na tu zprávu nejdřív musíte počkat a zpracovat jí. Ale ne na NMEA zprávu, ta čas na milisekundy nevypisuje...

podstata zařízení byla když mu přijde další pulz přiřadit k němu přesný (milisekundový) timestamp

Pak jste ale měl použít takový přijímač s PPS výstupem, který kromě času UTC poskytuje další informace, ze kterých se dá vypočítat odchylka 1PPS od UTC (na ms bez problémů). Některé přijímače toto opravdu umí, jen se nesmí používat NMEA, ale nějaký jiný protokol, nejspíš proprietární.

[Karry]

Těším se až padnou systémy všem kteří se neobtěžovali po posledním průseru aktualizovat Javu. Sázím na většinu tuzemských bank

[miros]

Nebyla to spíš chyba v kernelu, kterou java akorat spustila?

[Václav "Darm" Novák]

S tím časem je sranda

[Jendа]

Mimochodem všimli jste si, že poledne neplave o sekundy, ale během roku dokonce o čtvrt hodiny na každou stranu? Pojďme s tím něco udělat!

[frdrx]

Sekunda sem, sekunda tam.

[Conscript89]

vteřina sem, vteřina tam!!! :D viz