Un arreglo chapucero hace 20 está haciendo que el que "Efecto 2000" esté afectando a ordenadores en el 2020. Los programadores que querían evitar el error del año 2000 tenían dos posibles opciones: reescribir completamente su código, o adoptar una solución rápida llamada "windowing", que trataría todas las fechas de 00 a 20 a partir de la década de 2000, en lugar de la de 1900. Se estima que el 80% de las computadoras reparadas en 1999 utilizaron la opción más rápida y barata. Los programadores eligieron 1920 a 2020 como ventana estándar…
Comentarios
El asunto no es “los programadores decidieron”
Los programadores no deciden. Plantean. Repararlo bien vale XX.XXX euros (pesetas de aquella) y viene a ser rehacer el sistema, probarlo completo, etc o hacer la chapuza que cuesta la décima parte (o menos) y tirar p’alante y ya se arreglará.
Adivinad la solución que elige el que pone la pasta.
Y lo de arreglarlo más adelante, vuelve a pensar ¿me voy a gastar dinero en algo que funciona para que luego otro no tenga problemas dentro de 20 años cuando no esté en la empresa?
Vamos. Que no es cosa de los programadores, es cosa de los gestores.
#2 No son "3 o 4 sistemas". Como dice #1, es cosa de dinero, y lo que no entienden esos gestores que han decidido la chapuza en vez de la solución buena es que, siendo la tendencia gastar el menos dinero posible ("si funciona, ¿para qué lo voy a cambiar?"), los ordenadores/sistemas van a estar ahí in sæcula seculorum, y por eso se puede ver en los ordenadores de la Administración Pública, en los de Renfe, en los del Metro, etc., Windows 2000 Server, kioskos de información con Windows XP, sistemas embebidos con SSOO del año de maricastaña. Y cambiar SSOO/programas es más difícil cuanto más grande es la red que sirven, porque la adaptación puede costar un auténtico dineral, mucho tiempo de adaptación, incluso tiempo de interrupción del servicio, y eso hay empresas que no se lo pueden permitir, de modo que mantienen funcionando el sistema que ya tienen.
En Diciembre de 2017, los ordenadores en España con Windows XP y Vista eran el 5%. Si añadimos Windows 7, un sistema operativo de hace 10 años y con tres versiones por encima (Win 8, 8.1 y 10), nos ponemos en el 25% (sí, sé que W7 es un SO moderno que no tiene ese problema, pero sirve para ejemplificar la "resistencia al cambio"). En Dic19, XP+Vista = 2%. Y hablamos sólo de Windows: si miramos sistemas con distribuciones de Linux específicas que no se han actualizado en eones, igual tenemos que sumar algún punto más. Y eso no son "3 o 4 ordenadores".
Respecto a sistemas 32bits en 2038, me imagino que tendrán que tomar una solución de "marco temporal" o "windowing" similar al que se comenta en el artículo, pero por fuerza mayor, porque esos sistemas no permiten almacenar (o sus procesadores trabajar con) fechas en 64 bits. Es decir, cambiar el marco referencial, empezar a contar desde 2001 en vez de desde 1901. Eso le ocurrirá, por ejemplo, a mi Commodores Amiga, sistema de 32 bits, pero también a MUCHÍSIMOS sistemas de control 32bits instalados en máquinas, aviones, trenes, etc., etc., etc…
O sea que se han reportado 3 o 4 sistemas en todo el mundo con ese problema , pues ok.
Lo que sí me parece grave es que en 2038 los sistema de 32 bits volverán a 1901, y eso no tiene solución
#2 No es exactamente así: ya hace años que también en los sistemas de 32 bits se utilizan 64 bits para el epoch. El problema es, únicamente, de aquellos programas que siguen utilizando la API vieja, que, por compatibilidad, trunca el epoch a 32 bits.
¿De verdad alguien hizo algo parecido a eso? ¿Con lo fácil que era ampliar en dos dígitos las fechas, compilar y probar? (que modificar, compilar y probar, lo tenían que hacer de todas formas).
Desde luego, ya se complicaron la vida buscando hacerlo fácil, ya.
#3 En una aplicación para Windows creada en 1997, el "cliente" me pidió que solo pusiese dos digitos para el año... que era un palo tener que poner 19 delante cada vez...
Yo le recordé que en 2 añitos y medio ya estaríamos en el 2000... que mejor poner 4 dígitos, pero el empeñado que no, que el campo de fecha bastaba con tener 6 posiciones, DDMMAA.
Al final lo programé con 8 posiciones y pasé de sus especificaciones (no podía "arreglarlo" cogiendo el año del día actual ya que eran fechas con el año de nacimiento del asegurado).
Los usuarios finales lo aceptaron como hecho consumado y punto.
#4 En una aplicación para Windows creada en 1997
No me digas más.
#3 No pienses en sistemas de propósito general sino más bien en sistemas integrados, microcontroladores, etc. A veces ampliar un campo simplemente es imposible por otras limitaciones que nada tienen que ver con el código.
#5 Esos te los compro, yo siempre me he movido en informática de gestión.
#3 no has visto ninguna aplicación empresarial seria....
ese cambio al final es poner patas arriba la aplicación entera, revisar variables internas de fecha, bases de datos, interfaces de comunicación....
Amen de que muchos lenguajes admiten cosas tan brutas como "remapeado de variables", y las fechas son simplemente, unos "string" en los que puede (o no), contener fechas
#6 no has visto ninguna aplicación empresarial seria....
Dios mío, las cosas que tenemos que leer de vez en cuando.