Plusquam perfectum

Czy zauważyli Państwo, że przekroczyliśmy kolejną feralną datę, przy której komputery miały zgłupieć - 29 lutego 2000 r.? Pewnie nie wszyscy, choć na pewno nikt nie przeoczył przekroczenia daty 1 stycznia 2000 r. z powodu wrzawy w mediach.

Czy zauważyli Państwo, że przekroczyliśmy kolejną feralną datę, przy której komputery miały zgłupieć - 29 lutego 2000 r.? Pewnie nie wszyscy, choć na pewno nikt nie przeoczył przekroczenia daty 1 stycznia 2000 r. z powodu wrzawy w mediach. "Przestępna" odmiana tzw. pluskwy milenijnej nie zaatakowała, poza nielicznymi przypadkami.

Widać, że cisza w mediach jest skutkiem nauczki, jaką dostały one na początku roku. Wszyscy krzyczeli, że będzie koniec świata, a przynajmniej zawiodą istotne systemy, a nie stało się praktycznie nic. Gdy więc 29 lutego również nic się nie stało, wszyscy uspokoili się, że komputerowe błędy daty nie są tak groźne, jak na początku wyglądało. Można więc chyba powiedzieć, że Y2K jest czasem przeszłym, a nawet zaprzeszłym - po łacinie plusquam perfectum.

Wielu informatyków, którzy specjalizowali się dotychczas w pracach nad błędem daty, stanęło (albo stanie wkrótce) przed koniecznością znalezienia nowego zajęcia. Zapewne części z nich nie zaoferowano tak interesującej posady, jaką mieli dotychczas. Przeklinają więc dzień, w którym zgodzili się pracować w "projekcie 2000".

Chyba jednak i oni muszą się zgodzić, że jest to pewna "sprawiedliwość dziejowa", bo informatycy wreszcie płacą za błędy, które wcześniej popełnili. Problem tylko w tym, że jest to odpowiedzialność zbiorowa i rzadko kto poniesie w ten sposób konsekwencje własnych błędów. Uczestnicy zespołów ds. problemu roku dwutysięcznego raczej nie mieli nic wspólnego z tworzeniem aplikacji, które musiałyby być naprawione i monitorowane z powodu pluskwy milenijnej.

Myślę jednak, że problem ograniczeń związanych z zapisem daty został rozwiązany raz na zawsze. Poruszenie, jakie problem roku 2000 wywołał na całym świecie (przypominam, że np. amerykańskie służby dyplomatyczne radziły swoim obywatelom spędzenie Nowego Roku pod opieką Wuja Sama), sprawi, że w kontraktach na systemy informatyczne zaczną pojawiać się klauzule, wymuszające większą odpowiedzialność producenta za błędy daty. Poza tym jest jeszcze jeden czynnik: zmiana wszystkich cyfr w numerze roku grozi nam najwcześniej za tysiąc lat, więc nie bardzo jest się czym martwić.

Z pewną nieśmiałością przyznaję, że pluskwa, z której wielokrotnie drwiłem na tych łamach, zemściła się na mnie. Ugryzła niespodziewanie, choć niezbyt dotkliwie. Kilka lat temu napisałem dla mojego pracodawcy program, który przetwarzał dane z plików zawierających dzienne raporty sprzedaży. Nazwa pliku zawierała datę w postaci "fakturyYYMMDD". Program miał odczytać plik o nazwie konstruowanej dynamicznie, na podstawie parametrów podanych przez użytkownika. Niestety, algorytm nie wstawiał wiodącego zera w numerze roku (dla znających język C: w funkcji sprintf jako maskę użyłem %2d, zamiast %02d). W związku z tym np. 5 stycznia 2000 r. program szukał pliku "faktury 00105" (ze spacją w środku), zamiast "faktury000105". Błąd głupi i niewielki, ale efekt całkiem poważny - mój program przestał działać.

Wszystko skończyło się szczęśliwie, bo program nie był kluczowym elementem systemu, a jego źródła były pod ręką. Poinformowano mnie o tym w tonie żartu i ciekawostki, a nie pretensji. Pluskwa milenijna okazała się plusquam perfectum także w znaczeniu "doskonała", a nie "zaprzeszła", bo stała się doskonałą okazją do przekonania się, że problem był rzeczywisty. A przy okazji pozwoliła odświeżyć stare znajomości, co samo w sobie jest zaletą.

Z pewnym żalem i sentymentem zamykam temat i żegnam stworzenie, które dostarczyło nam tyle emocji i atrakcji w minionym roku.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200