Vlákno názorů k článku
Rok 2022 způsobil chybu v serveru Microsoft Exchange od Křišťan Surname - Proč mají všichni nutkání vymýšlet nové krkolomné způsoby...

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)