nejezdici vlaky
Jan Waclawek
konfera na efton.sk
Pondělí Leden 10 23:20:06 CET 2022
> Proè ? Unix timestamp je 32-bit _unsigned_, pøeteèe a¾ 7.února 2106 a
> z toho vìt¹inu z nás u¾ hlava bolet nebude.
Presne to si vraveli aj programatori v Cobole v 60tych rokoch, ked
odovodnovali dvojciferny rok.
Na "praxi" vo vypoctovom stredisku (EC1021, ale nepustili nas k nemu)
nemenovaneho narodneho podniku v roku 1985 som dostal za ulohu v zozname
majetku vytlacenom na asi kilometri traktoraku rucne vyhladavat polozky s
aktualnou hodnotou vyssou ako nadobudacia hodnota (dvojciferny rok
nadobudnutia vyssi ako 85 - vacsina 19.st., ale boli tam udajne nejake aj
z 18.st.). Nepytajte sa ma, ze preco rucne, dostal som len prikaz, nie
vysvetlenie. Pytal som sa, ze co s tym urobia; povedali mi, ze pre tieto
polozky zmenia rok nadobudnutia na 00.
> Problém roku 2038 je docela èasto zmiòován.
> Tak jestli náhodou v nìjakých knihovních funkcích (tøeba i starých, ale
> kdo furt upgraduje?) není pou¾ito pøetypování a zpracování jako int.
No, napriklad v newlib (pri pouziti na 32-bitovych targetoch) bol pomerne
nedavno (2018) opraveny bug suvisiaci s Y2k38
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commitdiff;h=3305f3557064a3cc981e3566959d7833bb81e192
a kym takato oprava premigruje do binarnych balikov a roznych IDE, to par
rokov trva.
>>> > 2201010001
>>> to je nìco, co je v nìjakém jazyce/specifickém hw elegantní a bì¾ný
>>> zpùsob ukládání data, lep¹í ne¾ unix timestamp?
"elegantny" a "lepsi" su v programovani - ako aj v realnom zivote - vzdy
kontextovo zavisle.
Mozno BCD ako take nema az tak vela pozitiv, ale separatne vedeny
den/mesiac/rok je daleko efektivnejsi na aplikacie typu "vyfiltruj zaznamy
z aprila minuleho roku" nez epochovite formaty casu.
Ta konverzia je prekvapujuco narocna a napriklad prave spominany mktime() v
newlib nie je ten najziarivejsi vzor optimalizacie, napr.
for (year = 70; year < tim_p->tm_year; year++)
days += _DAYS_IN_YEAR (year);
wek
----- Original Message ---------------
Problém roku 2038 je docela èasto zmiòován.
Tak jestli náhodou v nìjakých knihovních funkcích (tøeba i starých, ale
kdo furt upgraduje?) není pou¾ito pøetypování a zpracování jako int.
PL
Další informace o konferenci Hw-list