Vlákno názorů k článku
Přestupné sekundy mohou být nahrazeny přestupnou minutou, zato méně často od K> - Ale vlastne stejne moc nechapu problem. Kdyby vsechny...

  • Článek je starý, nové názory již nelze přidávat.
  • 7. 11. 2023 14:22

    K>

    Ale vlastne stejne moc nechapu problem. Kdyby vsechny systemy interne pocitaly jen sekundy TAI, a pak jen pro lidi by se vytvorila bijektivni mapa TAI-lidsky cas, tak by nebyly problemy, ne?
    Takze je problem jen v tom, ze nektere systemy ukladaji cas v lidskem formatu?
    (Teda ta bijektivni mapa by nefungovala do vzdalenejsi budoucnosti, protoze neni znamy pocet budoucich prestupnych sekund, ale to nevidim jako velky problem.)

  • 7. 11. 2023 20:29

    František Ryšánek

    Mám z toho podobný pocit. Paradox UNIX/Posix "epoch time" je zhruba ten, že počítá sekundy monotónně od 1.1.1970 a existenci přestupných sekund popírá, protože by se s nimi blbě počítalo, nicméně zároveň má epoch time běžet podle UTC, který přestupné sekundy ve skutečnosti tu a tam vkládá (zatím ani jednu neubral, ačkoli i tato varianta je teoreticky možná).
    Našel jsem relativně čerstvý popis, že linuxový kernel se s tím umí vypořádat relativně se ctí. Nerozmazává, prostě nechá dvakrát proběhnout sekundu 23:59:59, a kolem toho hlásí nějakými stavový flagy, že proběhne/probí­há/proběhla přestupná sekunda.

  • 7. 11. 2023 21:14

    M_D

    Ano, u poslední přestupné sekundy jsem u toho seděl a proběhlo to takto. Zkrátka proběhne 2x dokola čas 23:59:59, a to jsem se díval na nějakém relativně historickémn systému (asi Slackware 10, kernel 2.4.36). Problém to přinese jen starším systémům/kódům, kde není k dispozici/použit CLOCK_MONOTONIC pro časování, takže pokud se něco budí od CLOCK_REALTIME, tak se to při průchodu přestupnou sekundou fakticky vzbudí o sekundu později, než třeba chtělo, což může být někdy pozdě...
    On není tak problém přepočíst TAI na občanský, on je spíše problém opačným směrem, že jsou okamžiky, kdy to není jednoznačné. :-)
    Hm, také byly chvíle vize, že s UTC se nebude už sekundově přeskakovat, že zkrátka se UTC zavěsí na TAI, ale až přepočet na lokální čas by nebyl obvykle jen +/- celá hodina, ale hodina+sekundy.... Tohle snad už také padlo.

  • 7. 11. 2023 22:51

    Jan Hrach
    Stříbrný podporovatel

    > On není tak problém přepočíst TAI na občanský, on je spíše problém opačným směrem, že jsou okamžiky, kdy to není jednoznačné. :-)

    Mapování mezi „občanským“ a TAI podle mě jednoznačné je (občanský nemá žádnou sekundu dvakrát, má 23:59:60). Není jednoznačné mapování unixového.

  • 7. 11. 2023 22:53

    František Ryšánek

    Opět Vám děkuji za doplnění vzdělání :-) Tahle makra znám ze svého občasného hobby programování, ale této nuance jsem si nebyl vědom. Člověče v čem všem vy nemáte prsty :-)

    Ohledně sledování přestupné sekundy in vivo, vzpomínám si taky na jednu příhodu z natáčení: po přestupné sekundě na silvestra 2016/2017 se mi tuším začátkem března ozval zákazník, že na některých NTP serverech pozorovali zvláštní jev: na konci ledna, a následně i na konci února, na některých serverech došlo k opakování přestupné sekundy, lokálně v rámci serveru. A následně k její spojité korekci doladěním frekvence systémové časové základny, protože upstream zdroj času žádnou přestupnou sekundu neregistroval. Dost jsem se v tom nimral a zpočátku jsem měl dojem, že by se mohlo jednat o nějakou vzácnou interakci dvou serverů v "peer to peer" konfiguraci, které si "avízo přestupné sekundy" předají/podrží navzájem. Protože ty servery byly skutečně ve dvojicích. Později si ale někdo u Meinbergů vzpomněl na konkrétní bug v ntpd, který s topologií "dvou sousedů" zřejmě nijak nesouvisel. Ten bug byl v upstream ntpd opravený už někdy v roce 2012, můj zákazník provozoval na jaře 2017 starší verzi OS včetně ntpd. Problém vyřešila aktualizace, kterou zákazník dlouho opomíjel.