Este viernes a las 12 del medio día, exactamente, a las 12:34:56 asistiremos por primera y única vez en el siglo a la secuencia perfecta de dígitos 12:34:56 7/8/9.
Estas secuencias... o mejor dicho, curiosidades de juegos de números, siempre me sacan una sonrisa, e inmediatamente me hacen pensar en el famoso bug del milenio, ¿recuerdan al infame Y2K bug? No fue tan malo como muchos creían, más que todo porque el error estaba asociado a como se muestra la informacion, y no con su funcionalidad interna. Al final, todo mundo sobrevivió ese problemita. Pero hay un problema similar y vigente llamado Y2K38, que afecta a los sistemas sistemas de la familia Unix, y este bug es mucho más difícil de resolver. Una solucion practica es migrar a un sistema operativo, que use una representación de tiempo de 64 bits, sin embargo el problema persiste en sistemas de 32 bits. ¿Y quien usa sistemas de 32 bits?... los dispositivos móviles y pequeños reproductores de música.
Bien, pero seamos realistas, al paso que va la industria, para el 2025 espero que ya todos tengamos más 64 bits, y los dispositivos moviles probablemente también vayan por ese camino. Asi que, por ese lado estamos moderadamente seguros. Pero... el verdadero problema, esta en el software.
El tiempo en la computadora/ordenador...
El tiempo, en las computadoras, es representado por el número de segundos que han transcurrido desde el Unix epoch, es decir desde: 00:00:00 UTC Enero 1 de 1970.
Ese numero de segundos transcurridos desde esa fecha se conoce como un "timestamp", bien, muchísimos programas usan timestamp para obtener la representación del tiempo y mostrarnos la fecha actual, la fecha de la ultima modificación de un archivo, etc etc etc, el asunto es que estos mismo programas asumen que el tamaño de ese campo NO cambia (siempre es de 32 bits), entonces un programa de 32 bits, migrado (que se ejecute en modo de compatibilidad) a un sistema de 64 bits, leerá el timestamp correcto (de 64 bits) de manera incorrecta (lo leeria como uno de 32 bits).... ¡Ooops!
La situación es interesante, pero NO es fatal. Ya que no se ve realista seguir usando software de 32 bits en el 2038... al menos para mi, no lo es... pero el ciclo de vida de un software, puede durar mucho más de lo que esperamos y tal vez, alguien se verá en el problema de brindar soporte a aplicaciones antiguas (Legacy Applications)... Aquellos que lo hagan, no estarán en problemas por brindar soporte a una aplicación caducada, estarán en problemas por trabajar en empresas (o con empresas) que necesite "mantener viva" una Legacy Aplication para seguir funcionado.
Otros afectados por la falta de visión, o por el limite de un numero entero sin signo, es Twitter, que aparte de que ayer fue atacado (junto con FaceBook y LiveJournal) con una denegación de servicio, le llega el apocalipsis (otra vez) el 29 de Octubre de 2009. ¿Cuando tendremos que preocuparnos por otro infame bug de tiempo?, usando un timestamp de 64bits (con signo), hasta Diciembre 4 del año 292,277,026,596 ... para esa fecha, ya no tendremos preocupaciones.
La mayoria de defectos relacionados con el tiempo (timestamp, date bugs, etc) han sido de caracter cosmetico, y una vez aparentes, pues se pueden resolver bastante rapido.
Estas irregularidades me recuerdan dos cosas:
- Como le gusta exagerar a la gente los problemas
- Como nos gusta usar cualquier excusa para divertirnos un rato
time unix twitter linux apocalypse timestamp
Si quieren leer más sobre "el tiempo" en los sistemas Unix, pueden encontrar más información aquí.
