Rok 2000 a narzędzia dla programistów

Praktycznie wszyscy twórcy narzędzi dla programistów zamieszczają informację o 'zgodności' swoich najnowszych produktów z rokiem 2000. Jednak czy oznacza to, że posługując się starszymi wersjami tych narzędzi nie można napisać programu poprawnie działającego po upływie 'magicznej' daty 31.12.1999?

Praktycznie wszyscy twórcy narzędzi dla programistów zamieszczają informację o 'zgodności' swoich najnowszych produktów z rokiem 2000. Jednak czy oznacza to, że posługując się starszymi wersjami tych narzędzi nie można napisać programu poprawnie działającego po upływie 'magicznej' daty 31.12.1999?

Do każdego pakietu dla programistów dołączane są tzw. biblioteki, czyli pewien zbiór gotowych procedur, które realizują określone zadania. Do nich należy także obsługa dat. Programista, który pisze konkretny program, zwykle zakłada, że biblioteka działa poprawnie i nie zastanawia się, czy np. dana funkcja porównywania daty będzie działała dobrze po roku 2000. Można by więc powiedzieć, że to od bibliotek zależy, czy program napisany w danym języku będzie zgodny z kryterium roku 2000. Jednak nie jest tak do końca. Warto zauważyć, że możliwe jest samodzielne pisanie procedur operujących na datach - w takim przypadku programista uniezależnia się od producenta biblioteki. To, czy jego program będzie zgodny z rokiem 2000, zależy tylko od sposobu implementacji operacji związanych z datami oraz tego, jak daty te są zapamiętywane. Nie jest to rozwiązanie pozbawione wad, ponieważ może się okazać, że mimo iż programista jawnie nie korzysta z wbudowanych procedur bibliotecznych obsługujących datę, to biblioteka wykorzystuje te procedury.

Samodzielne pisanie procedur obsługujących datę nie gwarantuje więc bezbłędnej pracy programu. Na szczęście do większości kompilatorów dołączany jest kod źródłowy bibliotek i można samodzielnie (o ile nie zrobił tego producent) przeanalizować kod i poprawić implementację odpowiednich funkcji.

Producenci bibliotek zwykle wykorzystywali mechanizmy wbudowane w system operacyjny. Większość systemów dysponuje pewnymi procedurami wykonującymi operacje na datach - choćby funkcje zwracające bieżącą datę czy zapamiętujące datę utworzenia pliku. W takim przypadku ta zależność sięga głębiej - od systemu operacyjnego, przez bibliotekę, do programu. Mogłoby się wydawać, że wystarczy uruchomić taki program w systemie operacyjnym, który poprawnie obsługuje daty, i program będzie działał poprawnie. Może się jednak zdarzyć inaczej. Na przykład, kiedy wewnątrz programu (lub biblioteki, z którą program został połączony) rok będzie obcinany tylko do dwu ostatnich cyfr.

Ustalenie stulecia

Ważny jest sposób, w jaki program i/lub biblioteka traktuje daty, w których rok zapisany jest dwiema cyframi. Nowsze wersje narzędzi zwykle przyjmują, że jeżeli ten rok jest "zbyt" mały, jest to data z XXI wieku. Niestety, w zależności od programu są to różne daty! Na przykład większość produktów firmy Sybase przyjmuje, że jeżeli rok jest mniejszy lub równy 49, to należy do kolejnego wieku. Ale już Formula One, specjalny komponent dołączany do produktów Sybase, zakłada, że tylko daty mniejsze niż 19 należą do wieku XXI. Czyli rok 20 w bazie danych Sybase będzie traktowany jako 2020, ale gdy aplikacja skorzysta z Formula One i nie przekształci daty na postać z rokiem czterocyfrowym, to w tym komponencie będzie to rok 1920...

Kolejny problem może pojawić się w przypadku pisania programu, który korzysta z bibliotek dołączanych dynamicznie. Wtedy, jeśli zachodzi konieczność przekazywania dat między programem a biblioteką, należy być pewnym, że zarówno biblioteka dynamiczna, jak i program są zgodne z rokiem 2000.

Dobrym przykładem jest tu Windows i OLE. Co prawda typ daty w OLE pozwala zapisywać zakres dat do 9999 r., ale pojawia się problem z jednoznaczną interpretacją dat dwucyfrowych. Nowsza wersja biblioteki OLEAUT32.DLL (biblioteka odpowiadająca m.in. za automatyzację OLE) dokonuje konwersji daty z rokiem dwucyfrowym (granicą jest 29. rok). Starsza wersja (rozprowadzana z Windows 95) tej konwersji w ogóle nie wykonuje. Tak więc program, w którym użytkownik wpisuje rok dwucyfrowy, może wprowadzić rok 2010 albo 1910. W tym przypadku zmiana dotyczy wszystkich programów, które korzystały z biblioteki OLEAUT32.DLL (Access, aplikacje napisane w Visual Basic czy inne korzystające z OLE i data window). Czy w takiej sytuacji narzędzie programistyczne "zgodne" z rokiem 2000 może pomóc? Tak naprawdę nawet "ręczne" przekształcanie daty nie pomoże.

Oprócz niezgodności bibliotek z problemem roku 2000, warto pamiętać, że również środowisko dla programisty (IDE) może być niezgodne z rokiem 2000. Duży projekt składa się zwykle z wielu mniejszych plików lub podprojektów. Podczas budowy projektu rzadko zachodzi konieczność kompilowania wszystkich plików. Kompilator analizuje (zwykle porównując daty), który plik uległ zmianie. Wówczas trzeba go ponownie skompilować lub połączyć. To porównywanie plików z jednej strony zależy od systemu operacyjnego, a z drugiej, od narzędzia. Podobnie dzieje się z narzędziami do kontroli wersji - tam skutki nieprawidłowego porównywania dat mogą być katastrofalne.

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

TOP 200