Rok 2022 způsobil chybu v serveru Microsoft Exchange

Proč mají všichni nutkání vymýšlet nové krkolomné způsoby ukládání data a času? Lepší než unix timestamp (nebo monotonní čítače např. nanosekund obecně) to velmi pravděpodobně nebude... time_t má jediné úskalí (2038), a to je jednak dobře zdokumentované, a jednak ve většině případů už dnes vyřešené (64bit time_t).

IMHO je problém spíš v tom, že je to naopak nějaký historický relikt z 90. let (možná dokonce z 80. let), který tehdy pro určité účely dával smysl (tehdy se takové věci jako BCD běžně používaly), ale tehdy nikoho nenapadlo, že by to v té podobě vydrželo až do roku 2022 (přesně jako v případě "Y2K"), a mezitím se na to zapomnělo, dokud nenastal průšvih.

to ale není formát BCD, resp. minimálně to není formát BCD, tak jak byl navržen. Formát BCD by to byl kdyby to bylo číslo v šestnáctkové soustavě. V takovém případě ale mimochodem nehrozilo žádné přetečení za předpokladu konverze stringu do unsigned (a nikoli signed) typu (samozřejmě když opomeneme jistý detail, že to číslo má 10 znaků).

3. 1. 2022, 09:08 editováno autorem komentáře

Nepsal jsem, že to je BCD, napsal jsem jen, že tehdy se takové věci jako BCD běžně používaly. Osobně si myslím, že za volbou tohoto formátu stály podobné důvody jako ty, kvůli kterým se BCD a podobné formáty používaly. Mudrcům, kteří tu s převahou pár desítek let vývoje HW i SW vykřikují, jak je to idiotské a jak by za to vyhazovali od zkoušky, bych doporučil, ať si cvičně napíšou implementaci localtime_r(), vzpomenou si (nebo spíš vyhledají), jaký byl typický výkon tehdejšího hardware a pak ať se nad tím zamyslí znovu.

Já na ty MS řešení úplně expert nejsem, ale troufnu si tipnout, že v 80. ani 90. letech tam žádná anti-malware služba nebyla :-)

A ted si vemte, ze za takovy software nekdo plati... Mit na novem VW stejne sroubky a matky jako na Skode 1000 mi nevadi, to je lety provereny koncept, ale cokoli jineho bych chtel u noveho modelu auta nadesignovane od dob Skody 1000 nove, podle aktualnich navrhovych pravidel (pokud vysledek nakonec vyjde stejny, nevadi, ale dulezity je ten proces redesignu).

Vzhledem k tomu, že jde o anti-malware scanner, mám trochu pochybnosti o tom, že je to řešení z 80. nebo 90 let.

Spíš mne překvapuje, že ani firmy jako Microsoft evidentně nemají testovací prostředí, kde by software testovali s aktuálním časem posunutým o rok nebo o deset let dopředu. Trochu mne děsí, jestli tak netestují ani Windows.

Vzhledem k tomu, že jde o anti-malware scanner, mám trochu pochybnosti o tom, že je to řešení z 80. nebo 90 let.

Celé řešení ne, ale ta volba interního formátu může pocházet z něčeho staršího. Přijde mi to pravděpodobnější než že by takový formát pro ukládání časových známek někdo zvolil dnes, pokud by nebyl vázán kompatibilitou s něčím, co už ho používalo. Stejně jako si nemyslím, že by ty formfeedy ( ^L), které jsou dodnes k vidění v drivers/scsi/st.c v linuxovém jádře, byly záměr a ne jen pozůstatek copy&paste z nějakého staršího systému.

A vzoreček, který z unix timestampu získá rok/měsíc/den nebo jinou část data?

Vzoreček pro získání roku z 2201010001 je 2000 + x / 100000000 a např. pro získání měsíce je (x / 1000000) % 100. Vymyslet ho zvládnete s prstem v nose.

Takže ano, i tento divný formát má svoje výhody.

To jen přesouváte komplexitu jinam – jak by vypadala funkce, která ten Microsoftí timestamp inkrementuje o jeden den? Kolik větví tam bude podle měsíců, přestupných roků, přestupných sekund? :))

Unix timestamp je primitivní na straně zápisu a storage (dělá se často), komplexní na straně prezentace (dělá se vzácně). Tahle hrůza je sice jednodušší když se čte, ale zápis a (jak vidíme ve zprávičce) ukládání je minové pole.

A načo ho mám vymýšľať?

Tak šlo by využít toho, že den je číslo mezi 1-31, měsíc 1-12

(d+m*32+r*32*­16)*10000

31.12.2022 = 10356790000 (pořád se vejde i celým rokem)

Všechny násobky jsou mocniny 2, takže se dá posouvat

1035679 & 0x1F = 31
(1035679>>5) & 0xF=12
(1035679>>9) = 2022

No, zaprvý ti to 2x přeteklo přes uint32 (a int32 ještě víckrát) a zadruhé to neřeší problém komplexity - kdokoli bude chtít implementovat posunutí data o den, bude muset do funkce zahrnout kontrolu, který měsíc to je (jestli má 28/29, 30 nebo 31 dní), který rok to je (jestli je přestupný) a jestli ten rok není dělitelný 100 (pak není přestupný) nebo jestli není dělitelný 400 (pak zase přestupný je).
Navíc takto uvedené datum s časem oproti Unixovému timestampu není nezbytně unikátní ani sekvenční? Tedy, pokud přidáte možnost mít více než 60 sekund v minutě, tak je, protože pak to pokryje přestupné sekundy (a přestupné minuty), které jinak při blbé implementaci způsobí, že bude 2x vteřina 59 nebo vteřina 00 za sebou. To se v unixovém timestampu nestane, protože měří skutečný čas diferenciálně a ne podle nějakého šíleného systému. Vzhledem k tomu, že rychlost rotace Země se všelijak mění, tak není vyloučené ani to, že se v budoucnu budou sekundy ubírat, tedy by takto udaný čas ani při správné implementaci nebyl unikátní - jedna vteřina se 2x za sebou zopakuje.
A teď si vemte blbou funkci, která vám řekne, jestli mezi dvěma časovými daty uběhlo 24 hodin nebo ne. Tak v tomto případě taková funkce musí vědět, jestli v daném časovém úseku neproběhla přestupná sekunda. A pokud ano, tak musí zkontrolovat, jestli uběhlo 24 hodin + sekunda. U timestampu uděláte rozdíl a víte rovnou výsledek.
Při používání timestampu pro interní výpočty a převádění na lidsky čitelné datum jen v okamžiku, kdy je to nezbytné, může ušetřit přeci jen trochu výpočetního výkonu za předpokladu, že se provádí více výpočtů na datech než jejich zobrazení uživateli (např. hledání v databázi, po kterém se vyplivne jeden výsledek, tedy kromě konečného zobrazení se všechny opičárny s Gregoriánským kalendářem a přestupnými sekundami a minutami odstraní).

„To se v unixovém timestampu nestane, protože měří skutečný čas diferenciálně a ne podle nějakého šíleného systému.“

Tohle se protřepávalo na Rootu snad při poslední přestupné sekundě, kdy závěr byl takový, že unixový čas se též koriguje (dohledávat to už nebudu, ale pokud si pamatuju, tak to tam uváděl nejvyšší). Česká Wikipedie uvádí, že se nekoriguje, anglická zas, že existuje verze korigovaná (dle UTC) a nekorigovaná (dle TAI).

Takže?

Tohle měl MS-DOS u času souborů. Následky byly dva, protože se to nevešlo, tak sekundy mohly být jen sudá čísla, a Y2K znáš.

Až na to, že Y2K se zrovna z tohoto pohledu DOSu netýkalo, ten byl udělaný, aby fungoval do konce roku 2099 :) Údajně FAT16 podporoval až rok 2107, ale pak to může blbnout, protože to nemá ošetření skutečnosti, že rok 2100 není přestupný.

Jestli to chapu dobre, unix timestamp ma jednu nevyhodu - nejde vyjadrit moment, ktery se stal behem prestupne sekundy. Ale zase to je jeho vyhoda, diky jednodussimu prevadeni.

Podle mne ten čítač neslouží ani k převádění na čas. Myslím, že jde o to, aby to byly unikátní hodnoty, v čase rostoucí, a příjemný bonus je, že z toho čítače zjistíte den, kterého se to týká. Něco jako verzování – když budete potřebovat verzovat nějaká data a bude vám to vycházet na jednotky až desítky verzí denně, také skončíte u nějakého formátu třeba YYYYMMDD-XXXX. Akorát tady holt někdo vymyslel, že to úsporně uloží do 32bitového čísla…

Takže bude lepší data nešifrovat, protože "vzoreček" na dešifrování je moc složitý? A komprimovat budeme pomocí RLE, protože to vymyslí i středoškolák, zatímco Deflate je moc složitý? A text budeme ukládat v ASCII, protože je to mnohem jednodušší, než přepočítávat Unicode znaky z UTF-8...

Tohle asi nebude nejlepší argument. Primitivnost není vždy výhoda.

Tak a ted z toho zjisti jestli je to v letnim nebo zimnim case. ;o)

Co to je za zhovadilou implementaci? Za to bych vyhodil studenta od zkousky z libovolnyho predmetu, i kdyby nebyl zamerenej na programovani...

Neco jako BCD? Binary coded decimal? Pouzito pokud se nemýlím v biosu.

Není to BCD, viz. moje odpověď výše.

Ale jinak ano, RTC obvody (nejen ten co používá BIOS) to takhle kódují, protože se to snadno dekóduje do lidsky čitelného formátu.

3. 1. 2022, 09:09 editováno autorem komentáře

Tahle chyba by zasloužila pochod hanby. Kdyby se autor tohoto *nedorozumění* zamyslel nad limity, asi by rychle přišel na to, že datum 2201010000 a každá minuta poté je větší než svatých 2147483647. Po pětisekundovém zamyšlení by přišel s tím, že když už opravdu musí převádět* řetězec na integer, mohll by aspoň záznam data začínal měsícem a ne dvojčíslím roku a měl by řádně zkontrolovat vstup. Ani to ale neodpovídá na otázku "Proč?"

Proč se tu vůbec používá takový úchylný formát data? Koho vůbec napadlo převádět číselný řetězec na integer?

* v chybě se píše "Can't convert "2201010001" to long" . Hádám, že jde o snahu ušetřit pár bitů nebo pár řádků kódu.

tak long na 64bit systemech by to schroupnul v pohode. Problem je ten signed int.

long je 32-bit na 64-bit windows

A přesně proto je blbý nápad tyhle platformně náhodně fungující typy jako je "long" používat a místo toho by se mělo používat třeba "int64_t".

Po pětisekundovém zamyšlení by přišel s tím, že když už opravdu musí převádět* řetězec na integer, mohll by aspoň záznam data začínal měsícem a ne dvojčíslím roku

Po desetisekundovém zamyšlení by přišel na to, že s měsícem na začátku to nepude sortovat. Ale ani to ale neodpovídá na otázku "Proč?". :-D

Kdyby se autor zamyslel nad limity, tak se tato chyba nestala. Realisticky vzato se programátoři jen málokdy zamýšlejí nad limity datových typů a prográmátor této funkcionality nebude vyjímka.

Nad limitem datového typu by jste se měl zamyslet (a nejlépe i ošetřit) při každé operaci s proměnnou, včetně například operace +. A řekněme si upřímě, to nedělá nikdo. Mimochodem v některých jazycích (např C a C++) není chování overflow (nebo některých typů overflow) definováno, tím se (korektní) ošetření takové situace stává docela tricky.

Souhlas - jinak na tohle je paradoxně dobré začít potenciální programátory vzdělávat na Arduinu a podobných platformách. Jelikož má Arduino int jen 2B, náráží se na omezení rozsahem poměrně často a je docela zábava sledovat, jak nechápající student dostává "naprosto nesmyslná" čísla a marně přemýšlí, kde udělal chybu, protože opravdu musí svému kódu rozumět a nemůže se spoléhat na debugger, výjimky apod...

Zrovna nedávno jsem zadával úlohu na kreslení kurzoru (křížku) na malém oled displeji podle naklonění joysticku. Analogový vstup je 10bitový, displej má šířku 128 px, takže klasická trojčlenka na přepočet výchylky na pixely analogRead(A0)*127/1­023 dává parádně nesmyslné výsledky, pokud se nepřetypuje aspoň jeden argument na long :-).

A nebo na nejakem plne 32 bitovem processoru - treba Texas DSP TMS320C3x:
sizeof(char) = sizeof(short) = sizeof(int) = sizeof(long) = 1, ale to 1 je 32 bitu :-)
Takze clovek si pak do char ulozi 16milionu, a kupodivu to pak i nazpet precte!
To pak cloveka rychle prejdou takove manyry jako pretypovavat char[] na int * .....

4. 1. 2022, 10:24 editováno autorem komentáře

Může mi nekdo vysvetlit proc to neimplementoval pres knihovnu ktera by mu treba vygenerovala vhodny timestamp a delala konverzi zpet? Dost mozna bez typove konverze v hlavnim kodu.

Od mail serveru, který ani neumí posílat e-maily, mě to, že to neumí nakládat s datumem, překvapuje zrovna nejméně :-)

Prostě to nahákovali s tím, že se to fixne později. Nemají v MS pořád jejich legendární "nejslabší máte padáka"? V takovém prostředí se plánuje leda tak jak přečkat další kvartál.

No, uz jsem videl i PAN karty (tedy 13 az 19 cislic) ulozene v DB jako nejaky typ 'big integer'.
Akorat pak meli hosi problemy, kdyz jsme jim tam zacali posilat maskovany PAN kvuli PCI-DSS :-)

Jenže tohle je docela běžně používaný formát: YYMMDDHHMM.

Výhoda je v tom, že se podle něj dá řadit a je snadné a rychlé z něj vytáhnout jednotlivé části i bez znalosti přestupných roků a podobných věcí. Při použití UNIX time sice řazení funguje také, ale pro filtrování se člověk neobejde bez použití knihoven. A i zdánlivě triviální operace jako "který to byl měsíc" je ve skutečnosti výpočet na docela dlouho. Rozhodně ne pár řádků kódu, spíše pár stovek. Zkuste si třebas napsat vlastnoručně jak z UNIX time získat informaci, zda jde o datum v květnu (pátém měsíci).

Pokud potřebujete řadit a filtrovat obrovské množství dat na podmínky typu "rok 2021" nebo "květen", pak použijete právě něco jako je YYYYMMDDHHMMSS.

I když, popravdě jsem se už dlouho nesetkal s verzí YY, žil jsem v domění, že pár desítek let se používá jen YYYY.

PS: Víte, že MS Office má zabugované ukládání datumu jako čísla? V jejich verzi je rok 1900 přestupný a tudíž existuje datum 29.2.1900. A to by si člověk myslel, že na "počet dnů od 1.1.1900, včetně" nejde nic pokazit :-)

A to unix time ještě neumí vyjádřit libovolný čas a naopak mohou v budoucnosti existovat hodnoty, které budou neplatný unix time – protože unix time nepočítá s přestupnými sekundami. Takže pro vážnou práci s časem je to vlastně dost nevhodná reprezentace.

U toho přestupného roku 1900 v Excelu je to ještě zajímavější – ta chyba je v Excelu záměrně, kvůli kompatibilitě s Lotus 1-2-3.

> i zdánlivě triviální operace jako "který to byl měsíc" je ve skutečnosti výpočet na docela dlouho. Rozhodně ne pár řádků kódu, spíše pár stovek.

Triviální operace to není, ale stovky řádků snad nezabere...

Unix time je naprosto triviální, protože nemá přestupné sekundy.

A přestupné roky lze řešit tak, že se počítá v 400letých cyklech a celý timestamp se posune tak, aby první den v "roce" byl 1. březen (pak vychází poslední den v přestupném "roce" na 29. únor). Je to trik použitý v mnoha knihovnách a je to naprosto triviální naprogramovat (celá dekompozice je pak na pár řádků a je i úžasně rychlá, protože i když je timestamp 64-bit, tak ten 400letý cyklus se vleze do 32-bit).

Plně souhlasím. Navíc není větší frustrace než když vám pár hodin po novém roce začnou volat klienti, že se jim zřejmě nabořil Exchange a že něco neběží jak má. Google v té době také ještě nic neznal. Naštěstí to brečelo do logu ohledně convert to long ,tak, že mne napadlo antimalware filtr vypnout a mailflow se obnovil. Bylo třeba to vypnout na všech 2016 a 2019 Exchange, tedy tento problém někdo zanesl do Exchange ne zas tak dávno. Skvělý dárek k novému roku od MS. Už se těším na prohlášení od Microsoftu že na Exchange online tento problém potají již opravili a že je to důvod k migraci k nim. :)

Jako jo, když jsem četl, že se bug vyskytuje jen na on-premise řešeních, tak mě napadlo, jestli to není nějaká reklamní informace na přesun do cloudu :-D

Chyba je i v Exchange 2013, jen nezpůsobuje padání služby, ale jen nefunkčnost aktualizačního systému.

Takže ten kód existuje minimálně od roku 2012

Tak mně se to stalo taky. Jako variabilní symbol v účetnictví používáme obvyklý tvar YYMMxxxx, uložený jako integer (protože VS je číslo, že). Pak se to kvůli jednomu klientovi předělalo na YYMMxxxxNN, problém nebyl vidět, dlouho to fungovalo dobře...

Je to taková školácká chyba. Spíš mě překvapuje, že přelom roků nemají v testech, protože toto by vyplynulo. Číslování verzí tímto způsobem se dělává, je lidsky čitelné a zároveň po převodu setřiditelné. Ostatně, v DNS se zóny verzují podobným způsobem. Problém je převod na int32.

Já si matně vzpomínám, že na toto "přetečení" bylo upozorňováno v době, kdy se řešil fenomén Y2k. Tehdy se nám to ještě zdálo daleko a od té doby se na to zapomnělo.

OT: Oracle se pred par lety stalo neco podobnyho. Nepredpokladali, ze diky prestupne vterine bude mit minuta 61 vterin a RAC Clustery se o pulnoci hromadne rebootovaly.

Podobnej problém bude mít hádám více projektů, protože je to standardní formát pro generování čísel objednávek a variabilního symbolu na eshopech :-)

Nebo vyrobnich cisel. Co jsme si zazili u nas.

Většina eshopů je v nějakém vyšším jazyku, kde mezi variabilním symbolem a int32_t je dvacet vrstev abstrakce, takže přetečení nehrozí :-)

Otázkou je, jestli aspoň jedna z těch vrstev je BigInt. Jinak těch 20 vrstev abstrakce akorát důkladně maskuje to, že je tam nějaký int co by mohl přetéct.

Bývá to string... co jsem tak většinou měl tu smůlu vidět.

Tak string mi tu přijde jako celkem rozumná volba. Ona práce s daty bude vždycky humus, protože ten binec je už v zadání.

Ta smůla spočívá v čem?

Koukam ze indicti mistri neradi jenom v MS, ale Xilinx (ted pod AMD) se taky povedl :P

https://www.reddit.com/r/FPGA/comments/rut1dz/vitis_hls_20201_error/