Nowa pluskwa milenijna?

Archiwum

Moje najwiÄksze skarby i opowieĹci prosto z mojego

Nie wszędzie wyciągnięto wnioski z przygotowań do roku 2000. W styczniu tego roku pojawiły się kłopoty z niektórymi systemami komputerowymi. Poważniejsze problemy mogą być jeszcze przed nami.

Problem roku 2000 polegał na tym, że starsze aplikacje rozpoznawały rok na podstawie ostatnich dwóch cyfr. Metoda ta działała dobrze, dopóki obie daty pochodziły z tego samego tysiąclecia, poza nim mogły pojawić się błędy w obliczeniach. Przede wszystkim, mogły pojawić się w systemach, które muszą analizować odległe daty, na przykład obliczać wiek osób na przełomie tysiącleci. Dodatkowo, niektóre komputery (oraz inne urządzenia) nie były przystosowane do pracy po roku 2000, gdyż datownik w zegarze systemowym nie umożliwiał wprowadzenia właściwej daty.

Niezgodny sprzęt wymieniono, najważniejsze błędy zostały usunięte, w wielu aplikacjach pojawiły się odpowiednie modyfikacje, które wprowadziły obliczenia lat w formie czterocyfrowej. Aplikacje w systemie typu UNIX, korzystające z systemowego czasu, były wolne od tego problemu, gdyż nie obliczały w ogóle lat, a sekundy.

Niestety, nie wszędzie wyciągnięto wnioski z przygotowań do roku 2000. W styczniu bieżącego roku niektóre systemy odmówiły posłuszeństwa, gdyż źle traktowały rok 2010 - obliczały go dwucyfrowo przy nieprawidłowej implementacji przeliczania z systemu dziesiętnego na szesnastkowy i odwrotnie. Po nocy z 31 grudnia 2009 (rok szesnastkowo: 7D9) na 1 stycznia 2010 (szesnastkowo: 7DA) wadliwe systemy wskazywały rok 2016 (czyli 7E0), co z kolei powodowało nieoczekiwane załamania, nieprawidłową pracę aplikacji lub odmowę obsługi zleceń błędnie zakwalifikowanych na rok 2016.

Problem dotknął użytkowników niektórych niemieckich kart płatniczych EC, których mikroprocesory były wyprodukowane przez firmę Gemalto, przy czym sądzi się, że dotyczyło to części produkcji z jednej konkretnej linii. Problemy zauważono także w australijskim Bank of Queensland, gdzie terminale nieprawidłowo oznaczały transakcje datą z przyszłości. Informatycy banków opracowali zmienione oprogramowanie, które obchodzi ten problem, ale sam fakt zaistnienia tego zjawiska udowadnia, że nie wykorzystano doświadczeń związanych z nagłaśnianym problemem roku 2000, zwanym popularnie "pluskwą milenijną".

Błąd roku 2010 dotknął nawet użytkowników telefonów z systemem Windows Mobile (wersje 6.1 i 6.5) oraz Palm Pre WebOS. Zauważono go także w profesjonalnych, wykorzystywanych na szeroką skalę rozwiązaniach biznesowych klasy ERP. Oprogramowanie firmy SAP we wszystkich wersjach posiadało podobny błąd w obszarze kolejkowania (informacja SAP numer 1422843). Tym razem, przy domyślnych ustawieniach, nowe zadanie było tworzone z datą z roku 2100 (na przykład 2100-01-01) i pojawiały się problemy z jego usuwaniem. Przy domyślnych ustawieniach retencji, błąd dotyczył wszystkich żądań kolejki utworzonych po 23 grudnia ubiegłego roku.

Problem nie kończył się na systemach ERP. Jedna z definicji filtra bardzo popularnego rozwiązania antyspamowego, SpamAssassina, kazała traktować wiadomości przychodzące z datą 2010 r. jako spam. Niektóre programy antywirusowe źle obliczały daty i nieprawidłowo rozpoznawały sygnatury. Rozwiązania sieciowe również nie były wolne do niespodzianek - load balancer Cisco CSM miał problemy z wygasaniem ciasteczka, przez co sesja była ciągle przełączana. Problem rozwiązano, wprowadzając aktualizacje.

Nowa epoka UNIX

Wszystkie powyższe kłopoty wynikały z drobnego błędu w implementacji obliczeń daty, który można stosunkowo szybko naprawić. Znacznie poważniejszy problem jest jednak dopiero przed nami - dotyczy godziny 03:14 GMT, 19 stycznia 2038 roku.

Standardowo systemy typu UNIX obliczają datę jako liczbę sekund zegara liczonych od 1 stycznia 1970 roku (początek epoki systemów UNIX), bez uwzględnienia sekund przestępnych, wynikających z korekcji kalendarza do stanu zgodności z ruchem obrotowym Ziemi. Do zliczania używa się 32-bitowej liczby całkowitej ze znakiem, w której wartości ujemne nie są wykorzystywane. Przedział czasu, który można zapisać w takiej liczbie jest ograniczony i wynosi 2 ^31 minus jeden, czyli 2 147 483 647 sekund. Czas "unix time", obliczany z użyciem zmiennej 32-bitowej, wyczerpie się we wtorek, 19 stycznia 2038 roku o godzinie 03:14:07 GMT. Sekundę później zegar dzisiejszego standardowego systemu typu UNIX, wykorzystującego 32-bitową zmienną, wskazałby 13 grudnia 1901 godz. 20:45:52 GMT.

Dzięki tej metodzie obliczania czasu, w systemach typu UNIX nie występował nigdy problem roku 2000, podobnie w aplikacjach, które do obliczeń wykorzystywały czas w formacie systemowym. Między innymi z tych powodów profesjonalne aplikacje (z sektora energetycznego czy finansowego) pracujące w tym środowisku i napisane zgodnie z jego założeniami nie sprawiały problemów w 2000 r.

Chociaż do wyczerpania 32-bitowej zmiennej jest jeszcze dużo czasu i na pewno w oprogramowaniu nastąpi wiele zmian, proponuje się już nową standaryzację z przejściem na 64-bitową zmienną (time_t), która z powodzeniem wystarczy do końca ludzkości na naszej planecie.

Aplikacje, nie system

Dzisiaj największe problemy dotyczą jednak nie systemów operacyjnych, ale aplikacji. Jak widać, nadal powstają programy, które błędnie liczą lata. Przykład oprogramowania związanego z obsługą kart Gemalto udowadnia, że może się zdarzyć przypadek aplikacji, która liczy ten rok jednocyfrowo. Podobny przypadek może mieć miejsce na przełomie lat 2025/2026 (szesnastkowo 7E9/7EA), gdzie błędna aplikacja wskaże 2032 (czyli 7F0). Należy zatem wdrożyć uznane standardy, by uniknąć podobnych problemów w przyszłości i przygotować się do migracji na nowy system zapisu daty w maszynach typu UNIX.

Chociaż prawdopodobieństwo ciągłej eksploatacji dzisiejszego oprogramowania w niezmienionej formie aż do 2038 roku jest nieduże, producenci systemów i aplikacji powinni już zacząć przygotowania do wdrożenia nowego formatu daty. Modernizacja nie odbędzie się natychmiast, a należy pamiętać, że systemy core business (szczególnie w sektorze finansowym, gdzie UNIX jest uznanym od lat standardem) są projektowane w taki sposób, by działały przez lata. Prace trzeba rozpocząć już teraz.

Marcin Marciniak - Computerworld.pl

Nowa pluskwa milenijna?

Archiwum

Moje najwiÄksze skarby i opowieĹci prosto z mojego

Moje najwiÄksze skarby i opowieĹci prosto z mojego