29 de Febrero de 2000, un peligroso primo oculto del bug del milenio
Los peores problemas son aquellos que permanecen ocultos en la sombra para atacar en el momento apropiado, y conozco uno de estos problemas acechando al desprevenido usuário. Es un primo del llamado "Bug del Milenio" (o Y2K por su siglas en Ingles), también relacionado con el año 2000, y que probablemente atacará a muchas organizaciones y empresas el 29 de Febrero del año 2000.
Es conocido de la astronomía que la Tierra gira en torno al Sol a cada 365.2422454... dias. Esta parte fraccionária de 0.2422... es la razón por la que existen los años bisiestos (aquellos que tienen un día extra en el mes de Febrero). Si multiplica este número bizarro por 4 notará que a cada 4 años la Tierra avanza 1460.9689.. dias, o CASI 1461 dias. Bien, si los astrónomos insisten en mantener el año con 365 dias por motivos prácticos de redondeo, obtendrán 1460 dias a cada 4 años, y la Tierra habrá avanzado en realidad 1 día más de lo previsto, entonces, donde poner al día extra?. Para resolver este problema, Julio Cesar, emperador romano, estableció hace unos 2045 años el "año bisiesto" (que inteligentes eran estos romanos!), o "sacar de la nada" un dia extra, el dia 29 de Febrero. Así, a cada 4 años la Tierra avanzaría 1461 dias. Por causa de esta reforma, fue llamado de "Calendario Juliano".
PERO 1 NO es igual a 0.9689..., y por el año 1582 esta pequeña diferencia se había acumulado hasta exceder unos 12 dias sobre lo que la Tierra realmente había girado (1 - 0.968.. = 0.031.., multiplique esto por 1600 y divida entre 4 = 12.4 dias).
Este defasaje fué suficiente como para que la gente comenzara a darse cuenta que las estaciones climáticas estaban fuera de lugar, y aquel año (1582), el Papa Gregorio XIII estableció el "Calendario Gregoriano", cortando de raíz 10 dias (sí, despues de las 23:59:59 Hs. del 4 de Octubre de 1582 vino simplemente las 00:00:00 Hs. del 15 de Octubre de 1582, un verdadero año fatal!).
Esta es la razón por la que Ud. no encontrará documentos fechados por ejemplo como "9 de Octubre de 1582" entre los papeles del Vaticano. Ningún periódico, páginas Internet o cheques al portador tenían este tipo de fecha, y sospecho que también las tarjetas de crédito a vencer en aquellos días fueron canceladas, así como los viajes y paseos por Caravelas, Carrozas, trenes y aeronaves. Algunos países de religión protestante (Inglaterra...), esperaron hasta 1752 para cambiar el calendário, cortando entonces 11 dias en el mes de Septiembre de 1752 (en estos países la vida se congeló desde el 3 de Septiembre hasta el 13 de Septiembre de 1752).
Pero el Papa Gregorio también incluyó otra corrección, y ahora entra la parte de nuestro problema fatal. Para evitar futuros deslocamientos radicales en la fecha, estableció que a cada 100 años, el día 29 de Febrero sería ELIMINADO, o sea, no existen los dias 29 de Febrero de 1900 ni 29 de Febrero de 2100, mismo que estos años sean múltiplos de 4 (por favor verifique el comando "cal" de Unix y MS-DOS, los del Unix están correctos, algunos de MS-DOS están errados), y aún más, a cada 400 años el dia 29 de Febrero SÍ debería existir, mismo que estos sean años múltiplos de 100.
Si Ud. calcula estas operaciones, notará que lo que Gregorio XIII estaba tratando era de ajustar en alguna forma la parte fraccionaria de 0.2422..., visto que 1/4 - 1/100 + 1/400 = 0.2425 (y aún existen otros ajustes por venir que no recuerdo exactamente cuando, pero a cada 4 o 5 mil años el 29 de Febrero también será eliminado, por favor me recuerde de colocar esta página de nuevo en el año 5000 D.C).
Habrá notado que dije "algunos comandos "cal" del MS-DOS están errados (si, algunos de ellos mostrarán a pesar de todo el dia 29 de Febrero de 2100 como siendo un Sábado). Por que?, por que los programadores utilizan normalmente una fórmula matemática aproximada para calcular los dias de la semana, o sea, resolver problemas como "que dia es el 31 de Julio de 1999? , respuesta: Sábado" dentro de sus programas y sistemas de ordenador. Los programadores Unix usaron una fórmula *buena*, algunos programadores sobre MS-DOS usaron una fórmula *no tan buena* para el comando "cal" (calendary), ya que algunos programadores se dejan llevar por la idea de que "si 100 años es una gran cantidad de años, entonces 400 años es una verdadera enormidad, nada que ver con *mis* sistemas". (note que el MS-DOS no tiene un comando 'cal' desarrollado por Microsoft, sino que algunos programadores independientes desarrollaron programas shareware - o de dominio público - para emular el comando 'cal' del Unix).
Algunas personas, al momento de escribir los programas, giraban la cabeza y preguntaban a los compañeros de trabajo ".. alguien por ahí sabe cual es la fórmula exacta para los dias en un año?", y como las enciclopédias Encarta y otras geringonzas electrónicas solo aparecieron después de 1990, puede imaginar que la respuesta no era facil de ser conseguida. Entonces muchos programadores y profesionales de la informática escuchaban de los compañeros "..hei, Pepe, creo que una buena aproximación es 365.24, usa esta fórmula que trabaja muy bien en mi sistema contable.." y esto era verdad, aquella fórmula habia funcionado perfectamente en los sistemas informátios durante los últimos 300 años. De esta forma, muchos sistemas contables, cuentas bancárias, posiciones accionárias, agencias de viaje, la CIA, agendas de la Casa Blanca, tienen probablemente dentro de algunos millones de líneas de código el número "bien aproximado" 365.24.
Bien, la verdad es que el problema esta doblando la esquina, por que el año 2000 *ES* un año divisible por 400, y para todos aquellos millares de programas equivocados, el 29 de Febrero de 2000 NO existirá porque el número 365.24 es aproximadamente suficiente para cortar los años bisiestos de los múltiplos de 100, y 2000 ES un múltiplo de 100, por lo que sin duda será afectado. Esto significa que para todas aquellas corporaciones bancarias, agencias del gobierno y agencias de viajes, despues del LUNES 28 de Febrero de 2000 a las 23:59:59, con seguridad vendrá el MARTES 1 de Marzo de 2000 a las 00:00:00.
Si cortar 10 dias en 1582 en tiempos de Gregorio XIII fué un problema enorme, Ud. puede imaginar lo que sería cortar solo UN dia en el año 2000, cuando la mayor parte de las personas en el mundo están reguladas por ordenadores.
La peor parte es que todas estas organizaciones y empresas no podrán continuar con sus operaciones en los dias siguientes HASTA que corrijan completamente el problema, por que mismo que los directores y gerentes ordenen que los relojes del ordenador sean retrasados un día a la mañana siguiente, mismo así estos insistirán en informar que el 1 de Marzo es un MARTES en vez del dia correcto: MIERCOLES. Que pesadilla!
Es real esta amenaza?, bien, si aún tiene dudas talvez deba ver AQUI e imaginar lo que sucederia si alguna institucion financiera de primer nivel descubre esto el dia 28 de Febrero de 2000.
En mi novela "El Canto del Cisne" (Segunda parte, aún sin traducción al Español), hablo un poco sobre el BUG del Milenio, y como algunos hackers usan esta falla para entrar en los computadores de agencias del gobierno para robar informaciones sobre un mensaje de origen extraterrestre guardado alli.
La sugerencia que daría a las empresas y agencias del gobierno es que prueben insistente y sistemáticamente las fechas contra el 29 de Febrero de 2000, y no apenas contra el dia 1 de Enero de 2000, por que esta falla puede ser más peligrosa que el bien conocido "Bug del Milenio".
Es seria la amenaza del 9 de Septiembre de 1999 (9/9/99) ?
Algunos forums y áreas usenet está discutiendo el problema del 9 de Septiembre de 1999, o sea, cuando los ordenadores lleguen a la marca de "9/9/99" podrian volver los contadores a cero como "0/0/00".
Esto sin suda que es una broma, las rutinas y algoritmos tratan los dias/meses/años en forma separada, así los meses vuelven a cero cuando llegan a 12, los dias cuando llegan a 28,29,30, o 31, dependiendo del mes, y los años cuando llegan a 99 (de aqui el problema del bug del milenio). Es imposible que algun ordenador "piense" que luego del "9/9/99" aparecerá el "0/0/00".
Algunas personas me han comentado que unos pocos antiguos programadores usaban la marca "9/9/99" para indicar "no tiene fecha" en algunos ficheros, luego cuando llegue la fecha del 9 de Septiembre estos programas podrian actuar en forma errática. Esto es posible pero creo que ocurrirá en muy pocos programas visto que la forma más usada para indicar "no tiene fecha" de manera que sea una fecha válida es en la forma "01/01/01" y "11/11/11", y para indicar "la mayor fecha posible" se usaba el 31 de Dic. de 1999. (de esto hace unos 30 años).
La otra historia sobre el 9 de Septiembre que cruza los newsgroups es como sigue: algunos programadores solían indicar "fin de fichero" o "default" con el string "9999" en ciertos lugares. Estos rótulos funcionaron bien, pero al llegar el 9 de Septiembre de 1999, la fecha formará un "9/9/99" y estos programas se comportarán nuevamente en forma errática al encontrar o grabar "9999".
Esto no es verdad por que aunque las máscaras de algunas fechas las muestren como "9/9/99", las fechas son guardadas internamente usando por lo menos 6 dígitos (2 para el dia, 2 para el mes y 2 para el año), así cuando el 9 de Septiembre de 1999 va al fichero lo hace en la forma de "090999" (sin máscara) o "09/09/99" (con máscara). Ninguno de estos valores combina con "999" "9999" "99999" o "999999" usados anteriormente.
Lo inverso también es verdadero: siempre que una rutina encuentre el número "9999" o "999999" en algún fichero, no podrá de ninguna forma interpretar como 9 de Sep. de 1999 por que los dos número a la izquierda serían leidos como "dia 99 del año 99" o "dia 99 del mes 99 del año 99", llevando a estas rutinas a un mal funcionamiento. Así, estas rutinas han fallado hace mucho tiempo y ya han sido corregidas.
Si desea conocer un poco más sobre el BUG del Milenio, tecle aqui.
Si desea leer el Kit de Primeros Socorros para el Bug, tecle aqui.
Si desea ir a la página principal tecle AQUI.
