Na jednom obsluznem programu pro PLC (Chronos Richardson, z roku asi 1992?) bezici na SCO 5.0 maji nazvy souboru (logy, recepty, ....) YYMMDD.......
V roce 2000 ze zmenil z 991231...... na a00101...... a nikomu to nevadilo. Nyni jsme na b70131...... a porad to jeste nikomu nevadi :-)
Zajimave bude, co se stane v 2060, jak to bude pokracovat - ale predpokladam, ze do te doby tato SW cast na SCO asi uz uplne umre :-(
Vzhledem k tomu, ze uz je problem i v Chronos Richardson z GB sehnat vubec nejake lidi, kteri o tom systemu jeste neco vi, tak je jasne, ze to bude takto 'hnit' dal ....
Ono uz kdyz v roce 2007(?) se do toho PLC (na bazi 8086) potrebovala pridat dalsi karta s analog vstupy (kvuli novemu mixeru a regulaci otacek) a nakonfigurovat ten obsluzny software na SCO aby s tim hral, tak jenom 'blba' tydenni navsteva nejakeho cloveka z Chronos Richardson byla z jejich strany nacenena na 1MKc :-(
Tak jsem si udelal dvoudenni vylet (all exclusive) za 15KKc cisteho na ruku ....
No paráda je, že články jsou pořád v db :-) https://www.root.cz/clanky/windows2000-ready/
Dokonce i s diakritikou!
Y2K byl velký problém. To, že se nakonec nic moc nestalo, je důsledkem toho, že se na to řada systémů roky připravovala. Takže správnější mi přijde postoj "zvládli jsme to" než "vždyť se nic nestalo".
Upravit některé systémy byl docela boj. Změnit v ERP typ pole s datumem by byl docela oříšek, navíc by se musela přepsat i aplikační logika. Proto se někdy autoři uchylovali k zajímavým hackům. Například původní pole bylo číslo na 6 míst. YYMMDD. Po úpravě byl formát YYYDDD. Kde YYY je počet let od roku 1900 a DDD je pořadové číslo dne v roce. Databázový formát zůstal stejný (number(6)), řazení, intervaly apod., to vše funguje jako dřív. V databázi bylo jen potřeba spustit script, který překonvertoval původní formát na nový. A pak samozřejmě změnit formuláře, aby správně zobrazily datum a kalendář.