TODO LO QUE USTED SIEMPRE QUISO SABER SOBRE EL
Efecto 2000...
DESPUÉS DEL EFECTO 2000.

DUDAS A PIE DE CALLE

Pregunta: ¿El problema era realmente grave o se ha magnificado?

Respuesta: Era grave... antes de solucionarlo. El problema del alarmismo ha venido que las informaciones dadas por los medios en los últimos días del año partían de datos obsoletos. Hablaban de los informes que justificaron el trabajo realizado posteriormente, siendo éste deliberada y maliciosamente ignorado con el fin de obtener titulares.

Las pseudo-noticias y correveidiles que se sucedieron en las últimas semanas de 1999 son las informaciones que deberían haber aparecido hace tres años para que se hubiese tomado conciencia a tiempo por todo el mundo y de forma adecuada y razonable. Pero aparecieron cuando ya, o estaba solucionado, o no tenía remedio.

Pregunta: ¿Es cierto que algunas compañías informáticas han engañado para vender más?

Es tan probable como que le haya engañado su periódico (se ha fijado que la misma noticia es diferente para cada uno), su carnicero, su abogado... En todo caso, si usted elige un profesional para sus necesidades lo es por comparación con otros. En una economía de mercado siempre se puede elegir. Es posible que haya habido "espabilados" o pequeños timadores, pero en general los gastos realizados y las inversiones realizadas tienen siempre una justificación detrás. Lo que ocurre es que los que lo cuentan no siempre están bien informados.

Hacer correr la voz de que se ha "engañado" con algo es demasiado fácil para algunos medios (sobre todo si están acostumbrados), demostrarlo es otra cosa, y desde luego, generalizar no suele ser bueno.

Si no obstante, usted se siente engañado, reclame... o cambie de asesor.

Pregunta: Pero lo cierto es que los informáticos se han forrado ¿no?

La informática es una profesión en la que el trabajador totalmente autónomo es una especie en vías de extinción. El "informático" en la mayoría de los casos trabaja para una empresa por un sueldo fijo (haya o no efectos dosmiles). Y como mucho, en algunos casos de los muy frecuentes en los que tiene que alargar su jornada muy por encima de lo normal, se le compensa con algún dinero extra que nada tiene que ver ni con el esfuerzo realizado ni con lo que en otras profesiones se paga en concepto de "horas extras".

Ningún informático que se sepa se ha forrado (salvo, por lo general honrosas, excepciones). O si no, que diga dónde y nos vamos todos ;)

Pregunta: ¿Pero no es verdad que las consultoras han ganado mucho dinero?

Sí.
Otra cosa es que ese dinero no se haya ganado honradamente. Cuando hay terremotos, las empresas constructoras hacen mucho negocio, pero eso no quiere decir (necesariamente) que se aprovechen ni que provoquen los terremotos. Mucho menos que se los inventen.

En los dos últimos años ha llegado a faltar personal para poder abordar la ingente cantidad de código por corregir. Muchas empresas dejaron de "vender" proyectos de año 2000 por la falta de personal para abordarlos. Otras tenían que acabar contratando personal poco o nada cualificado para afrontar la demanda y formarlo deprisa y corriendo (uno de los factores que podía influir en el resultado final).

En muchos casos se ha trabajado casi duplicando (o sin casi) la jornada laboral e incluyendo fines de semana, retrasando vacaciones, etc... (Esto de todas formas es muy frecuente en dicha profesión y casi nunca recompensado salvo con mantener el puesto de trabajo).

Por tanto, las facturaciones han sido elevadas debido a la gran cantidad de trabajo realizado, no a otros factores que se apuntan en determinados "medios".

Pregunta: ¿Se han vendido ordenadores nuevos con la excusa de que los antiguos no iban a funcionar?

Es posible... La picaresca no conoce fronteras, pero en la mayoría de los casos eso no es cierto.

Por un lado en lo que a equipos se refiere, la gran mayoría de éstos podían seguir utilizándose cambiando la fecha de modo manual una vez en el año 2000. Esto no era recomendable en servidores o sistemas que tuvieran que estar trabajando durante el cambio de año, salvo que fuese posible pararlos y arrancarlos de nuevo, pero estos eran muy pocos y por lo general eran sistemas más modernos y preparados.

Lo que sí es cierto es que tanto administración como muchas empresas han aprovechado la coyuntura para modernizar sus instalaciones y renovar el parque informático, a la vez que se han realizado inventarios más fiables lo cuál es tarea difícil y se pierde mucho dinero cuando un inventario no es fiable.

Hay que recordar que el parque informático Español, por ejemplo, estaba totalmente obsoleto hace escasamente un año lo que no permitía ni rendimiento ni competitividad. Con eso no hay que confundir el que la modernización se haya realizado a raíz de las acciones tomadas con respecto al efecto 2000 con el que se "haya cambiado un 486 que podía haber estado funcionando dos o tres años más". Si a alguien le han "vendido" un ordenador nuevo porque el antiguo no pasaba el 2000, que pida explicaciones a su proveedor o a quién le asesoró.

Nosotros ya explicamos cómo saber si un PC podía seguir funcionando en el 2000 o cómo hacerlo posible .

Pregunta: ¿Es cierto que sólo entre el 5 y el 10 por ciento del software estaba "impactado"?

No, más bien es una mala interpretación.
El porcentaje de impacto, mide la relación entre la cantidad de software en un sistema y la que iba a fallar por el Efecto 2000. Normalmente se jugaba con dos porcentajes: el de líneas impactadas y el de programas impactados. Es decir, el porcentaje de impacto en líneas era el resultado de divivir en cada programa el número de líneas con errores entre el número total de líneas del programa. Como una aplicación o una empresa, ministerio, etc... estaba compuesta siempre por muchos programas, el porcentaje de impacto en programas era el resultado de dividir aquellos en que se habían detectado errores entre el número total de programas analizados.

Así, el porcentaje de impacto en líneas venía a ser entre el 5% y el 10% en programas COBOL. En Clipper (había y hay un enorme número de aplicaciones todavía escritas en lenguajes derivados del dBase) venía a ser entre el 2% y el 4%, en C entre el 3% y el 7%. Si bien es cierto que cada programador o equipo de trabajo es un mundo, a la hora de obtener cifras globales es impresionante como la estadística impone sus reglas y lo uniformiza todo.

En cuanto al porcentaje de programas afectados, era muchísimo más alto. Del 30% al 70% como media, aunque podía llegar fácilmente al 90% y al 100%.

Hay que tener en cuenta que es más fácil que se dediquen recursos a desarrollar nuevas aplicaciones que a mejorar las antiguas ("Si algo funciona no lo arregles"), por lo que las empresas o instituciones que más pronto habían empezado a introducir la informática en sus procesos son las que más programas antiguos tenían.

Pregunta: ¿Entonces era cierto que iban a caducar los yogures de la nevera?

Ni mucho menos ;) La gama blanca de electrodomésticos nunca había estado afectada. Sí algunos videos pero muy viejos (como de hecho ha ocurrido), nunca los televisores ni algunas otras cosas de las que se han comentado. Pero eso no lo han dicho informáticos. Como mucho algún que otro tertuliano que se las diese de tal. En los informes que publicamos aquí mismo como en muchos de los que se han podido consultar en Internet incluidos los del propio MAP (Ministerio de Administraciones Públicas) que también dimos como referencia, estaba bien claro todo esto.

Pregunta: ¿Y eso de que se iba a ir la luz, a faltar el agua...?

Eso eran cosas que podían haber pasado si no se hubiese puesto remedio (de hecho, algún que otro apagón sí que hubo). Como ya informábamos al principio de nuestro artículo sobre servicios básicos . En países o zonas poco o nada informatizadas esto no era mayor problema (el problema suele ser más habitual) y en las demás se han debido revisar gran cantidad de equipos, sistemas y programas. Algunos se han debido sustituir, otros se han corregido y el resto estaba bien.

A veces las dependencias son tan extremas que los certificados de garantía 2000 de las compañías eléctricas indicaban que ellas funcionarían si lo hacían las telefónicas y éstas si lo hacían las eléctricas.

Hay que tener en cuenta también casos como el de Rusia que ante el enorme riesgo que suponía el estado de preparación para el 2000 de la red eléctrica, optó por cambiar el control a modo "manual" en la tarde del 31 de diciembre. Este tipo de medidas suele ser más difícil cuanto más automatizado está un sistema. Por lo general, cada vez se construye más pensando en que "todo funciona" y sin tener en cuenta otras posibilidades para el caso de que falle. Es una lección que debemos aprender después de esto.

Pregunta: ¿Cómo podemos saber ahora lo que hubiera pasado de no haberse hecho nada?

De dos maneras. Por un lado la gran mayoría del trabajo realizado está documentado. Los programas eran analizados y/o probados antes de ser corregidos. La mayoría de las informaciones sobre lo que podría pasar no eran meras especulaciones, sino resultado de pruebas realizadas.

Por otro, basta con echar una ojeada a las pocas cosas que están pasando (o que sabemos que han pasado) y pensar en lo que podía haber ocurrido si en vez de fallar un puñado de ellas, fallasen todas a la vez o una gran mayoría.

Pregunta: ¿Es cierto que están pasando cosas de las que no nos enteramos?

Lo es, pero se trata de cosas de media o pequeña importancia. Evidentemente si fuesen cosas graves no habría forma de ocultarlas a la luz pública porque lo veríamos.

De todas formas está en juego tanto el prestigio de los gobiernos como el de muchas empresas y organismos. Al haberse dado una cobertura mundial al asunto, ningún gobierno estaba dispuesto a reconocer ante los demás posibles fallos y quedar en ridículo ante la comunidad internacional, por lo que hubo países a los que les faltó el haber dicho que todo estaba bien antes de acabar el año. Por supuesto todos estaban bien aunque luego han tenido que ir reconociendo algunas contrariedades que han acabado saliendo a la luz.

En cuanto a las empresas ocurre algo parecido. A pesar de que en un proceso tan voluminoso es normal que se produzcan pequeños fallos, sobre todo porque muchas cosas no pueden ser probadas "en real" antes de suceder, a ninguna empresa le interesa poner en tela de juicio su prestigio reconociendo fallos que podrían mal interpretarse por el gran público. Sobre todo después de ver las maliciosas interpretaciones que la prensa está haciendo de todo esto.

No obstante, fallos o incidencias como los que damos a conocer en nuestra sección de , no deben interpretarse como que sí que se está produciendo un caos, sino como la mejor prueba y explicación de lo que iba a ocurrir de no haberse puesto remedio.

Pregunta: ¿Todavía pueden pasar cosas?

Sí, hay muchos procesos que se efectúan a final de mes o a principios del mes siguiente y que todavía están por ejecutarse por primera vez con fechas de 2000.

Es el caso de facturaciones, contabilidades, nóminas, algunos cargos o recibos bancarios, etc...

Ah, y no olvidarnos de que el 2000 es bisiesto.

Pregunta: Pero hay quien dice que el cálculo del año bisiesto en los programas se suele hacer sobre los múltiplos de 4, por lo que el 2000 se considera bisiesto... :?

Cierto, en la mayoría de los casos así es.
Los años bisiestos son aquellos múltiplos de 4 salvo los múltiplos de 100, a menos que sean divisibles por 400. Es decir, 1700, 1800, 1900 o 2100 no son bisiestos, pero 1600 y 2000 sí.

Dado que no se espera (sic) que los actuales programas sigan funcionando en el 2100, muchos programadores simplifican el algoritmo a que el año sea múltiplo de 4, con lo que 1996, 2000 y 2004 aparecen como bisiestos. Esto se da en un buen número de programas, pero desgraciadamente no en todos.

Existen algunos (los menos) que sólo tienen en cuenta que el 2000 es múltiplo de 100 y no lo dan por bisiesto. Otros (más frecuentes dentro de la excepción) aplican la regla completa, pero al trabajar sólo con dos dígitos ésta se aplica a 1900 con lo que dicho año "00" se da como no bisiesto.

Como casos muy excepcionales, se ha utilizado un algoritmo basado en que a partir de un determinado año del siglo XX expresado con dos dígitos, se va incrementando éste de cuatro en cuatro hasta que el año de la fecha actual entra en el intervalo entre dos bisiestos. Pero dicho algoritmo no funciona si el año actual es "00".

En definitiva, son pocos casos y es posible que hayan sido corregidos. La pregunta es: si falla alguno ¿me afectará a mí?

Pregunta: ¿El hardware reconoce el año bisiesto?

La mayoría de las veces sí, pero no siempre.
El día 29 de febrero al arrancar tu ordenador asegúrate de que la fecha es correcta. O realiza una prueba poniendo la fecha en el 28 de febrero a las 23:58. Apágalo, y enciéndelo al cabo de tres minutos comprobando si la fecha es buena. Si ha fallado, ponla bien a mano mediante el comando DATE o el Panel de Control de Windows. Es posible que debas repetir la operación si enciendes tu sistema más de una vez dicho día. En el supuesto caso de que hubiera fallado.

Pregunta: ¿Y que problemas puede haber por no considerar 2000 como bisiesto?

Básicamente dos: que dicho día no "exista" y por lo tanto no se efectúen operaciones programadas para esa fecha y que no se tenga en cuenta a la hora de calcular el número de días entre dos fechas.

En la primera categoría está el riesgo de que el hardware pase del 28 de febrero al 1 de marzo, y por lo tanto, en el día 29 se opere como si fuese 1 de marzo. Puede que procesos programados para el último día del mes no se lanzaran o que se lancen los previstos para el primer día. Esto es importante en el caso de contabilidades, facturaciones...

Hay que tener en cuenta que el ordenador puede tener una fecha bien o mal, y cada programa interpretarla de forma diferente. Así, el ordenador puede estar en el 29 de febrero, pero un programa ignorarlo o viceversa.

El otro problema es cuando se calcula el número de días entre dos fechas o se añade un número de días a una determinada fecha. Por ejemplo para vencimientos de pagos. Así una letra que debiera pagarse a los 30 días, podría retrasarse en uno.

Relacionado con esto está el hecho de que para efectuar procesos mensuales como por ejemplo facturar, los programas operan entre el primer y el último día del mes. Si el programa toma el último día del mes como el 28, las operaciones realizadas el 29 serían ignoradas.

Pregunta: ¿Porqué los programas de ordenador "se lían" con las fechas y dan años como 1900, 19100, 192000, 3900,...?

El primer problema que pueden tener es que obtengan la fecha del día del ordenador y ésta sea errónea.

Si este escollo es superado, las complicaciones vienen de manejar sólo los dos últimos dígitos del año, o de componer éste con una parte fija (el 19) y una variable (98, 99, 00...)

El caso más típico es dejar fijo el 19 e ir cambiando el resto, con lo que en el año 2000 se "pegan" los dos últimos ceros al 19 dando como resultado el 1900.

Cada lenguaje de programación tiene sus funciones para obtener la fecha del día y muy frecuentemente, para separar el año de ésta en un solo dato. A veces estas funciones son muy similares entre diferentes lenguajes, pero no siempre es así y algunos programadores no lo han comprobado a la hora de escribir sus programas en unos o en otros. Es muy frecuente que haya una función que devuelva el año y que esta lo haga con dos o con cuatro dígitos, pero esto no es una regla fija.

Así por ejemplo, en lenguajes como C o Perl, la función devuelve "el año en curso menos 1900", lo que permite almacenar años hasta 2155 en un solo byte. Hasta el año pasado lo que se obtenía era una cifra de dos dígitos (por ejemplo 99) lo que hizo a muchos creer que siempre devolvería dos dígitos. No obstante, 2000 menos 1900 da como resultado 100, que al anteponerle 19 termina siendo el 19100 que tantas páginas de Internet han presentado.

El caso anterior no debe confundirse con lo que ocurre en javascript como se ha dicho en varios medios. La función correspondiente de javascript devuelve "dos dígitos si el año es menor que 2000 o, cuatro en caso contrario. Así, si la fecha se componía anteponiéndole un 19, el resultado es 192000. Si por el contrario se aplicaba la regla de C o de perl (son lenguajes muy parecidos todos ellos) de sumarle 1900 al año obtenido, el resultado suele ser 3900.

Pregunta: Pues después de leer todos estos "porqués" yo sigo teniendo dudas... :?

No hay ningún problema, escríbenos un mensaje y trataremos de responderte.