Data ukryta w polu złożonym

Często nie dostrzega się problemu, gdyż znaczenia poszczególnych pól nie kojarzy się od razu z datą. A są to pola używane zwykle do identyfikacji danych i mające kluczowe znaczenie dla aplikacji. Jeśli numer zamówienia jest zapisany w postaci:

to w zależności od sposobu przetwarzania tego numeru i danych związanych z zamówieniami, w roku 2000 możemy napotkać niemal wszystkie problemy wymienione w poprzednich punktach. ZM980212003 - trzecie zamówienie z dnia 12 lutego 1998 r.

Data zapamiętywana jako informacja dodatkowa

Czasem data nie jest obiektem operacji ani kluczem sortowania, a użytkownik jej nie ogląda. W przyszłości może się jednak okazać, że chcemy ją wykorzystać w inny sposób i to zmusi nas do rozwiązywania tych samych problemów co z datami znaczącymi.

Problemy z pełnym rokiem

Jeśli nasza aplikacja posługuje się wyłącznie datami 8-cyfrowymi, to też należałoby sprawdzić, że "pójdzie" ona w roku 2000. Warto to uczynić co najmniej z kilku znanych powodów. Jeśli aplikację napisała grupa programistów, można z dużym prawdopodobieństwem założyć, że w każdej grupie jest co najmniej jeden programista, który ma swój, na ogół niechętny, stosunek do narzuconych standardów. Często daje temu wyraz w pisanych przez siebie programach. Może np. samodzielnie założyć, że programy te nie będą wykorzystane po roku 1999. Wówczas nic nie szkodzi, by zacząć używać dwóch początkowych cyfr (tylko od czasu do czasu) do innych celów, oszczędzając pamięć na inne zmienne.

Jeśli aplikację napisano na podstawie dawnych programów, w których daty były 6-cyfrowe i logika operacji wykonywanych na datach była dość skomplikowana, to jest prawdopodobne, że logika ta została przeniesiona do nowej aplikacji bez oglądania się na rok 2000. Wystarczyło "podrasować" komunikację z użytkownikiem i widzi on poprawne daty 8-cyfrowe. Dzisiaj już nikt nie pamięta o tym, co zostało we wnętrzu programu. Wówczas to, co wkrótce zobaczymy na ekranie, może nas bardzo zaskoczyć.

Gdy aplikacja wymienia dane z innymi programami, które pracują z danymi o datach zapisanymi w różnych formatach, zwykle używa się prostego programu pośredniczącego, przekształcającego daty z jednego formatu na drugi. Program taki często dostawia po prostu "19" do 6-cyfrowych dat przesyłanych przez inną aplikację. W przyszłości możemy mieć więc kłopoty spowodowane nie tylko błędnym działaniem innej aplikacji, lecz także programu pośredniczącego. Ponadto jeśli grupa zajmująca się inną aplikacją postanowi przystosować ją do roku 2000, zmieniając strukturę danych i zapomni o tym poinformować, to konsekwencje zdążymy odczuć jeszcze przed oficjalnymi obchodami nadejścia roku 2000.

Każda aplikacja jest tworzona i pracuje w pewnym otoczeniu sprzętowo-programowym. Tym otoczeniem jest sprzęt i zakupione oprogramowanie systemowe i narzędziowe. To, że produkty zostały wykonane przez potentatów na rynku komputerów i oprogramowania, wcale nie znaczy, iż są odporne na problemy roku 2000 (np. zegar systemowy na PC może wrócić do roku 1980!). Co prawda problemów tych nie wykryje się poprzez patrzenie w kod programów, ale warto pamiętać, że jest to najpoważniejsze zagrożenie dla poprawnie napisanych aplikacji.

Problem roku 2000 to problem złożony. Aplikacje użytkowane w danej firmie czy instytucji nie są jedynym powodem do obaw. Lecz nawet jeśli dana firma ignoruje ten problem, nie chce lub nie może użyć kosztownej metodologii jego rozwiązania, spróbujmy przyjrzeć się naszym programom. Lepiej przyjrzyjmy się im dokładniej...

<hr size=1 noshade>Adam Dutkowski przez kilka lat pracował w Stanach Zjednoczonych w dużych korporacjach, uczestnicząc w prowadzonych tam przygotowaniach do nadejścia roku 2000. Obecnie jest właścicielem polskiej firmy konsultingowej Ecosoft.