El año 2000 y los problemas que traerá consigo siguen siendo la causa
de muchas conversaciones, actualización y de productos para testeo de
equipos y aplicaciones, pero no sólo hay que vigilar el día en el que
el calendario cambie de año.
Todos los expertos parecen estar de acuerdo en una cosa, no se podrá
bajar la guardia durante mucho tiempo, aun pasado el 1 de enero del
2000. Tan sólo un ocho por ciento de los errores que puedan darse por
el cambio de fecha tendrán lugar dicho día. Los tres próximos años
serán susceptibles a la aparición de errores y problemas con igual
probabilidad a la de cualquier otro día.
Otra fecha clave será el tres de enero, ya que el primer día del año
cae en sábado y muchas oficinas no abrirán hasta pasado el fin de
semana. Pero incluso fechas más avanzadas en el año pueden
considerarse peligrosas, ya que no todas las aplicaciones se ejecutan
todos los días.
Otras fechas a tener en cuenta son los comienzos del año fiscal, que
en muchos casos suele tener lugar a mediados de año. Para muchas
organizaciones el verdadero peligro del 2000 se sitúa en esa fecha y
no en otra. Por ejemplo el gobierno americano inicia el año fiscal el
1 de octubre del 2000, mientras que el japonés o el canadiense lo
hacen el 1 de abril.
Además hay que tener en cuenta que un error en cualquiera de los
sistemas puede afectar y extenderse rápidamente a otros ordenadores
conectados a él. Por eso no hay que prestar solamente atención a un
día en especial, no basta con poner la fecha del ordenador a 1 de
enero y comprobar que todo funciona correctamente, los tests deben
ser mucho más profundos.
No sólo habrá que prestar atención a los ficheros de datos, las
aplicaciones, scripts, etc. que hagan uso de ellos también deberán
ser testados y modificados para aceptar las fechas con el año en
formato de cuatro dígitos. No servirá de nada modificar las fechas
en un fichero de datos, si tras él existen aplicaciones que no
reconocen correctamente dicho formato.
Deja una respuesta