On pensait à raison que les programmes informatiques utilisés pour la gestion risquaient de s'arrêter de fonctionner ou produiraient des résultats erronés. Cela parce que la date système du matériel informatique (hardware) ne comportait que deux chiffres pour l'année, sans le siècle, et que les logiciels et bases de données présentaient le même problème, avec seulement les deux derniers chiffres pour l'année. Ainsi, l'année 2000 serait représentée par 00 et ne suivrait pas 1999 (99) dans une séquence numérique. Ceci risquait de créer des calculs et des comparaisons de données avec des résultats incorrects.
On pensait que les systèmes embarqués, dans la mesure où ils obéissaient à une logique similaire, risquaient de ne plus fonctionner, entraînant le dysfonctionnement d'outils et d'autres infrastructures cruciales dans les systèmes industriels.
Dans les années précédant 2000, quelques entreprises et gouvernements, lorsqu'ils ont fait des tests pour déterminer les impacts potentiels, ont rapporté que des systèmes critiques auraient besoin de grandes réparations ou risqueraient des problèmes sérieux. De 1997 à 1998, des estimations incertaines et alarmistes rapportaient à propos d'entreprises et d'industries une faible préparation de l'évènement. L'imprécision de ces rapports et l'incertitude des possibilités que le bug de l'an 2000 se produise ainsi --que des centaines de milliards de dollars soient dépensés dans la correction du problème,-- furent une raison majeure de la peur du public. Des comités spéciaux furent établis par les gouvernements pour analyser les travaux nécessaires pour éviter le bug, particulièrement pour les infrastructures cruciales comme les télécommunications, afin d'assurer que la plupart des services critiques soient prêts au 1er janvier. À partir de 1999, même si les mêmes organisations et gouvernements prétendaient être bien préparées, la confiance du public n'y était plus.
Aux États-Unis surtout, la presse a beaucoup communiqué dès 1996, notamment sous l'influence de Peter de Jaeger, avec comme corolaire des craintes millénaristes.
Certains estiment que cette psychose aurait été volontairement alimentée par des entreprises informatiques dans le but de pousser les consommateurs et les professionnels à s'équiper de matériel informatique plus récent. Dans la plupart des cas, les modifications étaient en réalité justifiées. Il faut dire que si le problème avait été anticipé plus tôt, il aurait coûté beaucoup moins cher !
Un label « compatible an 2000 » fut créé et attribué aux matériels informatiques censés ne pas souffrir du passage à l'an 2000.
Ce n'est que le passage sans problèmes à l'année 2000 qui a complètement écarté les craintes du public.
Le bug de l'an 2038 devrait affecter les systèmes Unix en 2038. En effet ces systèmes utilisent le nombre de secondes écoulées depuis le 1er janvier 1970 (cette date « 0 » est appelée Epoch) pour exprimer les dates. Or en 2038, le nombre de secondes écoulées devrait dépasser les capacités de stockage des nombres signés sur quatre octets. Sur les variantes d'Unix représentant ce nombre de secondes avec des entiers non signés (ce qui, pour des raisons techniques, est peu fréquent), le problème se posera en 2106 (le 7 février 2106 à 6 h 28 min et 15 sec en temps universel). Pour éviter ce problème, il faut stocker la date sur un plus grand nombre de bits. Avec l'arrivée de systèmes 64 bits, il sera possible de stocker des dates à plus de 250 milliards d'années dans le futur. Cependant bon nombre de logiciels continuent à utiliser des représentations sources de malentendus (mm/jj/aa, jj/mm/aa, aa.mm.jj, etc.).