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.