Linux a rok 2000

bravenec na optimit.cz bravenec na optimit.cz
Pondělí Červenec 12 12:23:26 CEST 1999


Radek Vybiral wrote:
> 
> On Mon, 12 Jul 1999, Fellow wrote:
> 
> > Zdravim,
> > v dubnu tady probehlo nekolik mejlu o roku 2000 v prostredi Linux.
> > Pracuju v armade a pripojuji citaci z armadni smernice, jak se datum
> > zpracovava v Unixu. Mohl by se nekdo z pritomnych odborniku vyjadrit,
> > zda se citace da 'prevest' i na Linux?
> >
> > Citace:
> > "Unix zpravidla pouziva pocet sekund od 1.1.1970 a tento pocet uklada do
> > 32 bitu, maximum je 2 147 483 647 sekund a prave 19.ledna 2038, presne v
> > 3:14:07 se z onoho maximalniho cisla stane opet nula. Nektere aplikace
> > se potom razem ocitnou v prvnim lednu 1970, nektere ovsem v 13.12.1901.
> > Problem vznika v knihovnach, na kterych je postaven Unix. Ty dokonce
> > pouzivaji pro cas pouze 31 bitove cele cislo se znamenkem. Samozrejme,
> > rok 2000 je blizko, tak proc se zabyvat necim, na co je 40 let cas."
> >
> 
Ano, tato citace se da prenest i na Linux.
Moc se o tom nemluvi, ale v UNIXu je i jiny problem. Neni to primo
chyba,
ale pokud si nektery programator prilis zjednodusi praci, muze se v jeho
programech objevit zanedlouho datum 1.1.100 :-)

man ctime
struct tm { .... int tm_year; ...
The number or years since 1900.

Dalsi - tentokrat vylozene zavaznou chybou - je starsi program clock.
K videni je v RedHat 4.2 - novejsi RH (od verze 5) pouzivaji program
hwclock.
Program clock s rokem 2000 vylozene neumi pracovat. Do RH jsem to
hlasil,
pritom se zadna oprava neobjevila a RH proklamuje verzi 4.2 jako
vyhovujici.
Ale mozna, ze jsem pouze opravu nezaregistroval.

Dalsi "chyby", o kterych jsem cetl, se po blizsim prezkoumani a
otestovani 
ukazaly jako kachny.

Pokud potrebujete vyjadreni o roku 2000 pro auditora, ukazte mu
prohlaseni RedHat
a nic vic. Pokud potrebujete vyjadreni pro klid sve duse, budete to
muset na Internetu
hledat pro kazdy jednotlivy program zvlast :-(

Petr Bravenec


Další informace o konferenci Linux