Hay muchos informes de sistemas que no lograron comprender el año 2010, pero no tengo idea de por qué. Los sistemas actuales que cuido funcionan bien hasta donde yo sé, pero me gustaría saber cuál es el verdadero problema para buscar mejor.¿Qué está causando los errores de 2010?
¿Alguien podría arrojar algo de luz por favor?
Editar: http://www.rte.ie/business/2010/0105/bug.html - Información sobre lo que afecta a las tarjetas de crédito en Alemania
Varios protocolos utilizados en la banca y las telecomunicaciones - including the SMS protocol - codifique el año como BCD en un solo byte.
De 2000 a 2009 se podría hacer fácilmente el error de interpretar el año como un número binario estándar ya que la codificación sería el mismo:
Encoding Binary-interpreted BCD-interpreted
0x01 2001 2001
0x02 2002 2002
...
0x09 2009 2009
0x10 2016 2010
...
Eso es probablemente la causa del error de Windows Mobile.
Tengo un sistema de trabajo que utiliza un campo de año de un dígito. Sí. Un dígito. Entonces la razón por la cual este sistema está fallando es que "2000" se expresa igual que "2010".
De lo que me enteré fue de soluciones rápidas que la gente hizo para el Y2K sin pensarlo dos veces. Entonces, si xx < 10 entonces 20xx else 19xx.
Realmente no se explica el 16 –
¿De dónde vienen 16? La pregunta solo pregunta sobre sistemas que no comprenden 2010. 0x10 = 16 podría ser una razón, seguro. –
El error de 2010 a 2016 puede no ser el único error aquí ... Esto bien podría explicar el problema que están teniendo los bancos alemanes. –
Una posible explicación se encuentra en el artículo siguiente
http://www.theregister.co.uk/2010/01/05/symantec_y2k10_bug/
Me recuerda a su reciente artículo sobre correcciones de errores Y2K baratos y sucios, donde algunos programadores sin escrúpulos ponen en un simple si < 10 = 20xx lo contrario la fecha es 19xx
Sí, creo que lo has clavado. –
Windows, actualmente, tiene la misma cosa. Los años de dos dígitos se interpretan como una fecha entre 1930 y 2029. Lo que hace que el código sea 'si <30 = 20xx; de lo contrario, la fecha es 19xx'. La solución es golpear a la gente, voluntariamente, usando años de 2 dígitos (incluidos los usuarios finales) –
SpamAssasin tenía una regla para marcar fechas demasiado lejos en el futuro como spam:
/20[1-9][0-9]/
La solución llegó unos días de retraso, pero es bastante simple:
/20[2-9][0-9]/
Nos vemos de nuevo en diez años.
Primero pensé que debes estar bromeando. Pero luego revisé https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6269. No parece demasiado difícil para mí comparar dos enteros de 4 dígitos entre sí. ¿Por qué usan expresiones regulares para eso? –
Porque todo el mundo sabe que, si no puede expresarlo en un Regex, simplemente no vale la pena hacerlo ...;) – GalacticCowboy
¿Puede evitar las conversiones de cadena a enteros? –
Puede deberse a los jóvenes desarrolladores que comenzaron sus carreras después del año 2000 y están usando 1 dígito para representar el año.
¿No sería esto más característico de un desarrollador anterior que tiene más experiencia (a) minimizando estas representaciones y (b) desarrollando los sistemas donde es más probable que esto suceda? –
O podrían ser los consultores de Y2K quienes no ganaron lo suficiente para jubilarse :) –
Me ocupé de un pequeño fallo de 2010 en un sitio el pasado fin de semana, sin embargo, fue el resultado de un descuido en la codificación.
alguien pensó que sería una buena idea para establecer el valor de un elemento de la lista a la dateTime.year.Now actual() cuando la lista sólo contenía artículos hasta 2009.
ddlItem.findByText(DateTime.Now.Year.ToString())
Aquí es una captura de pantalla de la protección Norton de Symantec endpoint
alt text http://img695.imageshack.us/img695/4500/152010112800am.jpg
muy bonito que nadie @ Symantec informó a sus clientes ... Hasta que el artículo fue publicado: http://www.theregister.co.uk/2010/01/05/symantec_y2k10_bug/
Es que hay un error en un componente que divide el año en dos partes. La segunda parte se usa en una comparación para que el dígito 10 no esté en la base 10, está en la base 16, lo que significa que es 0x10 = 16 (hex).
Utilicé Google Code Search para find y2010 bugs in open source software. Busqué un patrón particular que indicara un error (uso de "200% d" como cadena de formato printf) y encontré varios proyectos con ese error. La aplicación creativa de patrones de búsqueda probablemente podría aparecer más tipos diferentes de errores.
Oh cariño, eso es terriblemente vago. ¿Tienes algún enlace para compartir? –
Escuché algo sobre la interpretación de '10' como número hexadecimal. – Gumbo
Es solo una preparación para el apocalipsis de 2012. –