DURDIN: na druhou stranu, kromě jednočipů už je dnes všechno 64bit a prostě se to zrekompilovalo už dáno. Epochalypsa daleko víc hrozí embeded systémům, než nějakým PC. Zase je otázkou průměrná životnost embeded systémů. Ale ano, můžou se kousnout podle mě typicky nějaké léta neaktualizované ovladače, které porovnávají dva timestampy třeba kvůli stisknutí tlačítka po dobu alespoň 1 sekundu, apod. Bál bych se tlačítek ve výtahu, které už nejsou mechanické, ale právě nějaké dotykové s číselným displejem, ale dost staré na to, aby tam byl nějakej bazmek, kterej umí nejvýše 32bit integer... přesně takovéhle hračky, vyrobené někdy třeba v první vlně jednočipů v 90kách, mají šanci se kousnout, i proto, že ty postupy embeded programování tehdy ještě byly celkem primitivní a přímé čtení klávesnice byla nutnost u kdečeho (sám jsem s jedním takovým bazmekem, kde sem musel číst numerickou klávesnici přímo přes kernel, kdysi náhodou přišel do styku...). Typické zneužití porovnávání dvou timestampů jestli jsou aspoň sekundu od sebe budou různé sensory a tlačítka. Ve většině přiípadů ale nebudou fungovat jen tu jednu sekundu během přetečení, jen u hodně netypické aplikace přestanou fungovat navždy. Je dost možné, že i u chybně implementovaných systémů si nakonec nikdo ničeho nevšimne, maximálně se někde setříděné položky začnou řadit na začátky seznamů, ale ten typ zařízení, který bude postižen, většinou žádné sofistikované displeje neměl....

Evropská povodeň v roce 1342 byla ničivější, než ta u nás v roce 2002
St. Mary Magdalene's flood - Wikipedia
https://en.wikipedia.org/wiki/St._Mary_Magdalene%27s_flood

QWWERTY: Na nápravě obojího se ale už taky nějaký ten rok usilovně pracuje. Na druhou stranu, y38 problém vidím jako mnohem závažnější, než y2k, už z pohledu toho, že pokud aktuálně datum přeteče, nejsme v roce "00", ale v prosinci 1901. A taky, kolem roku 2000 to bylo relativně jednodušší, hardwaru zas tolik nebyli, navíc vývoj HW šel rychle kupředu, takže nebyl problém ho vyměnit, u toho co nešlo, byli na živu a aktivní ještě vývojáři, kteří ho uměli opravit. Dnes, při tom, kolik toho ve světě je, spousta výrobků které nikdy aktualizaci neviděly, různé smartphony, IOT, atd, je problém mnohem rozšířenější.

ATOMIKS: a nebo pretece neco dalsiho...

Year 2038 problem - Wikipedia
https://en.wikipedia.org/wiki/Year_2038_problem

a za 100 let znova...
"Systems using unsigned 32-bit integers will overflow in 2106."

mírně zajímavý fakt je, že (někteří) lidé narození po Y2K nemají vůbec tušení, co byl problém Y2K .o)
jiným mírně zajímavým faktem je, že stále ještě existují oblasti IT, kde to jednoho dne přeteče

GLADILAF: Pardon, nějak jsem z toho plochosvěta AD 2025 paranoidní: někdo řekne "y2k byly velký obavy," hned očekávám "a podfuk, nic nehrozilo."

GLADILAF: Někdo měl obavy, my jsme v roce 1999 slavili Vánoce v lednu 2000, protože muž byl tak dva měsíce v práci nonstop.

QWWERTY: A od té doby (devět let!) se zjevila řada různých řešení a workaroundů, jako třeba CLOCK_MONOTONIC. https://www.baeldung.com/linux/timekeeping-clocks

Já netvrdím, že je to zívačka. Jenom teda "others would never be admitted" a "pandemic proportions" je teda hodně přes čáru na opačnou stranu.

GLADILAF: Ne, to nebylo. To bylo taky _práce_, aby se to stihlo. Ale nevadí: "údržba je neviditelná, TUDÍŽ zbytečná. Nespadlo to, takže přece ani nemohlo!"

To mi připomnělo fenomén Y2K, to bylo taky obav...

PISKVOR: na jednu stranu "bu bu bu". na druhou si pamatuju, ze jsme 2016 zastavili deployment, dostali jsme novy patch release a narychlo delali deployment do LTE site, protoze RHEL mel last-minute leap second fix :))
BZ#836748, BZ#836803
After the leap second was inserted, applications calling system calls that used futexes consumed almost 100% of available CPU time.
This occurred because the kernel's timekeeping structure update did not properly update these futexes.

pritom to nebyla prvni prestupna vterina co RHEL/kernel zazil. a vsadim se, ze tehdejsi patching urcite vsude neosetril operace na druhou stranu / s negativni korekci, takze opatrnost je na miste

SALVATOR: Co to je, co to je, co to je, co se to děje? To svět se posral.

KURE: "Bu bu bu! Jo a říkali jsme, že zrovna na tohle poskytujeme konzultace? Ale levný to holt neni no..." (hodně strašení na to, že spousta infrastruktury je rádo, když je plusmínus ve stejným časovým pásmu, neřkuli ve stejný sekundě) Méně alarmistický pohled zde: https://packetpushers.net/blog/ntp-leap-smearing-what-is-it/

NELLAS: protože mě hrubě zklamalo že v článku nebylo ani píp o hrůzách negativní sekundy, tady je něco málo víc:

Should we be concerned? Nobody can say, since we’ve never had a negative leap second. But there have been problems with every normal leap second insertion. Many issues have been documented, but others would never be admitted by companies or governments. So far, none have been of pandemic proportions, but databases have been messed up and commerce disrupted. And every year we get more and more dependent on computers, so once again nobody knows what to expect next time.

It’s the timekeeping community’s job to inform the public and to promulgate best practices [4]. Masterclock routinely tests its products for compatibility with positive and negative leap seconds, and I’m sure other companies do too. The bigger problem is with society as a whole. Just like there is no limit to human folly, there is no limit to what bad computer programming can do – especially since most programmers never even heard of leap seconds.

Will We Have a Negative Leap Second? | Masterclock
https://www.masterclock.com/will-we-have-a-negative-leap-second.html?mwg_rnd=6116896

NELLAS: A já proč je mi furt na blití.