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