PARCHE Y2K

¿Qué es lo que pasará con la llegada del año 2000? ¿Caos total? ¿Desorden informático? ¿La necesidad de reprocesar varias veces porque los datos no checan? ¿Una ligera molestia? ¿Nada?

Analistas y expertos en diversas disciplinas auguran un desastre. Brithish Airways dice que tendrá equipos y tripulaciones en tierra durante la transición de año porque no tiene garantías de que todo funcione como debe (el gobierno chino se vió más hábil en esto, ya que obligará volar la noche del 31 de diciembre de 1999 a todos sus ejecutivos que no trabajen en el problema). Las grandes compañías y gobiernos han iniciado toda una industria del Y2K-compliant (lease certificación). Los clientes (y las empresas mismas) preguntan continuamente que es lo que la gente y empresas están haciendo al respecto para salvarse del armagedón informático. Hay quien dice que habrá problemas no serios y que pasarán desapercibidos. Hay quien dice que no pasará nada hágase lo que se haga. Caos, misterio y desinformación. Lo cierto es que lo único que pasará es nada.

Sólo pasará nada; no porque el asunto sea una broma o algo sin importancia, sino porque en mayor o menor medida la mayoría de las empresas, organismos e instituciones (públicas y privadas) habrán hecho algo o harán algo al respecto (incluso en nuestro país que tiene fama de dejar muchas cosas para la última hora). De manera que de haber algún problema, éste pasará desapercibido y sin mayores efectos.

Los antecedentes.
Primero, hay que señalar que este problema ya cuenta con un precedente. El popular equipo IBM 360 no podía manejar fechas más allá del 31 de diciembre de 1969. Pocos se dieron cuenta de esto, hasta que por toda Europa los sistemas comenzaron a caer conforme se aproximaban al límite en sus cálculos. IBM corrigió el problema con un parche de largo plazo.

Segundo, es importante recalcar que el problema no se debe a la llegada del nuevo milenio. El año 2000 es el último año del siglo XX; la llegada del nuevo milenio será hasta el 1o de enero de 2001.

Como ya todos sabemos, el llamado bug del milenio es provocado por el hecho de manejar el año con sólo dos digitos (ya sea por conservar espacio de almacenamiento, compatibilidad con sistemas previos o por considerar que el siglo en las fechas es irrelevante, pero que se trata de una convención no escrita adoptada por muchos durante largo tiempo). Ciertamente muchos de los sistemas actualmente en operación no se esperaba que estuvieran en funcionamiento para estas fechas, después 10, 20 ó hasta 30 años. Causa del problema es que también acostumbramos poner el año al final de la fecha, a manera de los dígitos menos significativos.

De cualquier modo, nuestro manejo y representación de fechas nos ha traído dolores de cabeza. La programación y funcionamiento de todo dispositivo, proceso y mecanismos basados en tiempo debe ser revisado, y si tomamos en cuenta que el resover los problemas diarios ya era de por sí un reto, sin tomar en cuenta la necesidad de cambio e inovación, veremos que se trata de una tarea descomunal (mas no imposible).

Y hasta ahí debió quedar el asunto, pero la mercadotecnia y los medios tenían que entrar en escena. El problema fue sobreanalizado, las consecuencias exageradas. Comenzó a haber pánico y desconfianza. Unos a otros comenzaron a vigilarse para ver si estaban haciendo algo, comenzaron a haber certificaciones, los productos comenzaron a mostrar etiquetas de estar a prueba de problemas con la llegada del año 2000, se crearon organismos, areas y departamentos de control de calidad en la trasformación al año 2000. Miles de cuestionarios comenzaron a fluir a través de internet, correo y faxes para saber quien estaba haciendo qué y cómo.

Cientos de empresas comenzaron a brindar asesoría sobre el tema. Artículos, conferencias y proyectos fueron escritos, impartidos y establecidos. Se desenterraron manuales, los programadores con dominio en COBOL, PL/I, Fortran y algunas lenguas muertas fueron llamados a lineas (con mejores salarios que en sus respectivas épocas). Empresas se creaban y muchas otras se especializaban sólo en el problema del año 2000.

La definción del problema.
Brevemente, este problema abarca lo siguiente:

La representación del año usando sólo dos dígitos provoca que al manipular fechas se presenten fallas aritméticas, de comparación, de ordenación, y de entrada y salida a bases de datos y archivos.
Uso de algoritmos incorrectos que consideran años bisiestos al ser divisibles por 400.
El manejar valores constantes empotrados en el código relacionados con fechas, como los dígitos "19", y el uso de valores especiales (llamados "números mágicos") como el "00" o "99".
Problemas relacionados a desbordamiento en registros relacionados con fechas.
Las soluciones.
Ante todo, lo primero era adoptar un estandard en la representación de las fechas, para el cual ya existía uno. El formato ISO 8601 es la solución perfecta, ya que la fecha es expresada en el formato CCYYMMDD. Esto no sólo soluciona el probrema de incluir el siglo en la fecha sino que también ordena los elementos de la fecha de manera que el año son los dígitos más significativos y los días son los menos significativos y así efectuar comparaciones de orden directas.

Los problemas relacionados con números mágicos, años bisiestos y desbordameinto de registros o variables puede ser corregido de manera limpia y directa. Al final es sólo un asunto de corección de algoritmos y redefinición de las estructuras de datos.

Los problemas relacionados con fechas con otra cosa e involucran el estudio del código y propósito de la aplicación para determinar el método más adecuado a seguir. Las posibilidades de solución adoptadas para este asunto fueron:

Expansión.
Esta solución implica el cambio del formato de los dos dígitos usados para el año a cuatro dígitos (YY --> YYYY), incluyendo todo aquello a lo que se haga referencia: estructuras de datos, variables, registros en archivos (actuales e históricos), bases de datos, variables de ambiente del sistema operativo, etcétera. La solución no sólo es la más completa y la mejor, sino que asegura que sus aplicaciones funcinarán adecuadamente por los próximos 2,600 años.

Codificación.
La información del siglo se codifica en un espacio de seis dígitos, que puede ser hecho de cinco formas distintas:

Codificación de fechas Julianas completas en un campo binario de 48 bits, i.e. usando 6 bytes (YYMMDD --> BBBBBB).
Codificación del campo de fecha como un desplazamiento (offset) o tiempo transcurrido en días desde una fecha específica, e.g. desde el 1o de enero de 1900 y que dicho sea de paso funciona también para los próximos 2,600 años (YYMMDD --> DDDDDD).
Codificación del siglo con un dígito (1 para 1900, 2 para 2000 y así sucesivamente) y reemplazo del mes y el día con el día del año (YYMMDD --> CYYDDD).
Codificación del siglo con un dígito y expresión del mes en base 12 (0-9, A-B), representado como M' (YYMMDD --> CYYM'DD).
Codificación del año completo usando dos bytes; que permite representar 65,536 años en un rango de -32767 a 32768 (YYMMDD --> BBMMDD).

Desplazamiento.
Si el problema sólo consistía en la aritmética podía recurrirse a algunos trucos con números. Por ejemplo, mientras que la diferencia 99-93=6 es correcta, 00-93=-93 no lo es en términos de años entre las dos fechas. Sin embargo, (00+7)-(93+7)=07-00=7 nos da el resultado esperado (i.e. aritmética en módulo 100). Por supuesto la constante a usar deber ser correctamente elegida si se desea tener disponibles y válidas otras propiedades de la fecha resultante del cálculo como el día de la semana. De aquí que el usar 28 (por las propiedades existentes en un ciclo de 28 años) sea mucho más lógico.

Ventanas de tiempo.
Esta solución sólo funciona si la aplicación se mantiene dentro de un período de 100 años. La ventaja es que no requiere cambio en el formato de datos, sólo en los programas.

Puentes.
Para los casos en los que no se tiene el código fuente de la aplicación por lo que no es posible efectuar modificaciones sólo se tení la alternativa de usar puentes o programas de interfaz. Estos programas son externos a la aplicación o sistema y actuan de intermediarios con el entorno operacional. Podían ser implementados mediante el método de ventanas de tiempo, o retrocediento el reloj del sistema y sumando o restando 28 años a la fecha de entrada o salida del programa.

Substitución o retiro.
En muchos casos la mejor alternativa fue el de "borrón y cuenta nueva". La substitución de sistemas o equipo (o el definitivo apagado o eliminación) fue muy bien vista si se debía a razones organizacionales (renovación de equipo, fusiones, ventas, cambios de domicilio, etcétera).

Abstención.
Una solución después de todo consistió en no hacer algo. No se trataba de ignorar el problema sino que después de determinar los riesgos, costos y alternativas contra el hacer nada se veía que era mejor dejar que el mundo siguiera su curso natural (válido sólo si no se tenían sistemas dependientes del tiempo).

Como puede verse el problema con el manejo de fechas fue el meollo del asunto, de lo que se desprende que ciertas fechas fueron objeto de especial atención y parámetros de prueba para las correcciones efectuadas; y de las que podían encontrarse ciertas dependencias. La siguiente tabla enlista y describe estas fechas.

Fecha Observación
1998-01-01 Inicio de año en el que pudieron comenzarse trabajos de ajuste y conversión.

1999-01-01 Inicio de año en el que pudieron comenzarse trabajos de ajuste y conversión.
1999-09-09 Presencia de números mágicos.
1999-10-10 Primer fecha que ocuparía los 8 dígitos y para la que ya habría adecuaciones en producción.
1999-12-31 El día previo al desastre.
2000-01-01 El día del desastre.
2000-01-03 Primer día hábil en la era del desastre.
2000-02-29 Día que hace bisisesto al 2000.
2000-01-10 Primer fecha de nueve caracteres en la era del desbordamiento de los años de dos dígitos.
2000-10-10 Primer fecha de diez caracteres en la era del desbordamiento de los años de dos dígitos.
2000-12-31 Día 366 del año del armagedón informático.
2001-01-01 Inicio del siglo XXI.
2100-01-01 Año no bisiesto.
3000-01-01 Año no bisiesto.

Tabla 1.- Fechas de prueba.

Los resultados.
Finalmente, ¿qué es lo que pasará? Bueno, que llegará el año 2000 y continuaremos desarrollando problemas que resolver para el año 2100 ó 3000. Todos los problemas que se esperaría ocurrieran un poco antes y a partir del 1 de enero del 2000 ya se habrán presentado, habrán sido anticipados o habrán sido corregidos desde inicios de la década de 1990.

Lo que si es de esperarse es que llegue el 3 de enero del 2000 y nos encontremos con empresas, organismos, áreas, departamentos y personal que nos sobran. Veremos que el costo de la solución ha sobrepasado por mucho las expectativas iniciales (principalmente porque se invirtió más en gente, papeles y publicidad que en la solución al problema: la competencia por ver quien se había dado cuenta primero del problema o quien tenía la solución definitiva).

Del llamado armagedon informático tan anunciado, sólo se presentarán algunos incidentes. Y, es casi seguro, en la mayoría de éstos, un despreocupado e ingenuo operador solucionará el problema ajustando el reloj de la máquina o cambiando una variable de ambiente al año de 1900.