Básicamente son los siguientes:

• Fallo en la "transición" al año 2000.
• Incapacidad de manejar fechas con los años de cuatro dígitos.
• No reconocer el año 2000 como bisiesto.

Fallo en la "transición" al año 2000.

Es decir que al acabar el último segundo del último minuto de la última hora del último día del año, la fecha resultante no sea el primer segundo del año 2000.

Normalmente un reloj y un calendario son "contadores". Esto es, van contando por ejemplo, segundos. Cuando se alcanzan los 60 segundos en vez de poner el "60", se pone un "00" y los minutos se incrementan en una unidad. Cuando los segundos llegan a 60, las horas a 24, los días del mes al valor que corresponda y los meses a 12, se incrementa en uno el valor correspondiente.

Si contamos los años utilizando cuatro dígitos para ello, la secuencia será de 1998, 1999, 2000, 2001, etc... Si utilizamos sólo dos dígitos los valores esperados serían 98, 99, 00, 01...

Por lo general, estos sistemas que trabajan el año con dos dígitos suelen tener los dos primeros (el "19" o el "20") *preimpresos*. Y no cambian automáticamente cuando el 99 se ha convertido en otra cosa. Lo más normal es que se mantenga el "19" y se lo anteponga al "00", de dónde viene la famosa frase de "el ordenador se cree que está en 1900".

Otro problema menos conocido, pero también frecuente es que después del "99", venga el "100". Algunos sistemas devuelven el año como el resultado de restarle 1900 al mismo. Es decir 99 para 1999, 100 para el 2000, 101 para el 2001. En este caso, no habría problema seguramente si se sigue trabajando con dos dígitos o si se hace la operación inversa para obtener el año real. Es decir si se añade 1900 a la cifra resultante, sea esta 99, 100 o 101. Pero en muchos casos esta característica se desconocía por lo que se trataba el año como si fuese a tener siempre dos dígitos. El resultado puede ser inesperado, desde que se creen años como "19100", "20100", "1910", "2010" o simplemente la memoria reservada para el año se desborde y produzca fechas ilegibles o incluso que elprograma entero falle.

Incapacidad de manejar fechas con los años de cuatro dígitos.

Aún en el caso de que hubiéramos conseguido "pasar" al 2000. Es necesario que luego los programas obtengan la fecha del sistema con cuatro dígitos ya que muchas aplicaciones deben efectuar comparaciones o tareas que implican a fechas de antes y después del 2000.

Uno de los problemas más frecuentes consiste en que se mantenga ese "00" y que sea este el utilizado para efectuar comparaciones o determinadas operaciones aritméticas. Como ya hemos dicho, la pregunta "¿2000 es mayor que 1999?" no obtiene la misma respuesta que "¿00 es mayor que 99?" Lo que puede provocar por ejemplo que se rechacen operaciones del tipo "¿Este producto ha caducado?" o "¿Tiene este señor antiguedad en la empresa como para pagarle un suplemento?"

No reconocer el año 2000 como bisiesto.

Como es sabido los años bisiestos son aquellos múltiplos de cuatro, excepto los múltiplos de cien, salvo los que sí lo sean de cuatrocientos. Esta última parte de la regla no siempre se ha tenido en cuenta, por lo que en muchos casos febrero del año 2000 tendrá 28 días y a continuación vendría el 1 de marzo.

Esto influye en cáculos de número de días trancurridos entre dos fechas que puede desplazar en "uno" el resultado para, por ejemplo, calcular el día en que se debe efectuar un pago. Si este es posterior al 28 de febrero, el día resultante puede ser el anterior o el siguiente al real según cómo se hagan los cálculos. Es posible también que una tarea que se debiera realizar el 29 de febrero del 2000 se realizase el 1 de marzo o simplemente sea ignorada.