WWW EPI

Diciembre 1998

El efecto 2000 y las bibliotecas

Una interesante cuestión planteada por Tomàs Baiget inicia un nuevo, aunque breve, debate en IweTel:

"Como sabéis, se han comentado largo y tendido las consecuencias que tendrá el hecho de pasar de 1999 a 2000 en los programas de ordenador que sólo tienen previsto un campo de 2 dígitos para expresar el año.

Se habla, por ejemplo, de grandes costes en las empresas para adaptar sus sistemas informáticos; de que algunas compañías de aviación no volarán el día 1 de enero del 2000 por razones de seguridad del control aéreo; etc.

Algunas bases de datos, cuyos números de registro o de acceso empiezan por los 2 dígitos del año en que se introducen en la misma, lo cual sirve para poder limitar por años, tendrán que aplicar otro sistema de numeración.

Mi pregunta es si sabéis en qué medida el 'efecto 2000' influirá en los programas de automatización de bibliotecas y, en caso afirmativo, qué medidas han tomado vuestras organizaciones o vuestros proveedores de los programas".

baiget@sarenet.es

Javier Trujillo Giménez aborda la pregunta: "En Indra, empresa de tecnologías de la información para la que trabajo, no creo que tengamos mucho problema con el 'efecto del año 2000'. Como nos dedicamos a ello, entre otras cosas, supongo que nuestros 'chicos de soporte' nos arreglarán redes y PCs.

Pero para quien no sea del ramo, comprendo que tenga su temor. No soy ningún experto en el tema, pero no soy demasiado catastrofista al respecto. Y os diré por qué.

Para empezar, todavía quedan por ahí muchos paquetes de bases de datos que pueden no definir un campo como 'campo fecha'. Por ejemplo, en Clarity (parecido a Knosys) y muchos otros, es opcional poner por ejemplo, '15/09/98' ó '980915'; esto último el ordenador lo 'entenderá' como '980.915'. Así de 'mal' lo hice yo cuando trabajaba con Clarity, pero de esta forma podía buscar igual fechas que números. Con este método, el 'efecto 2000' queda totalmente descartado aunque, por supuesto, no lo hice así por esta razón (hay otras) y no deja de ser una chapuza.

Sin extenderme más, os diré que ahora y desde hace tiempo, nuestra base de datos es una aplicación a medida diseñada por un servidor y desarrollada por técnicos de Indra sobre Lotus Notes. Además, tenemos otras bases de datos sobre Access.

La solución al 'bug' del milenio tiene que venir de los propios fabricantes de software. No tengo ninguna duda de que IBM (Lotus) facilitará un 'parche' para que podamos seguir con Notes sin problemas. Supongo que los responsables de Sabini, Absys, TechLib o lo que sea tendrán la categoría técnica (por no decir moral) suficiente para facilitar ese 'parche' mágico que solucione los problemas cronológicos derivados del cambio de fecha. Algunos fabricantes ya lo proporcionan a sus clientes, y a Microsoft no le interesa que nuestros sistemas operativos de base dejen de funcionar (dejando de funcionar con ello nuestra aplicación).

Esto, por otro lado, nos va a servir para ver qué fabricantes se precian, cuáles son serios y nos solucionan el fallo del software tan bueno que ellos nos vendieron. Quizá se produzca una pequeña criba entre los buenos y los malos del sector, lo cual hasta puede ser positivo para ver el 'estado del arte' en bases de datos documentales y demás.

Ésta es sólo una cara de la moneda. La otra es a qué precio. El tema de la responsabilidad legal contractual del fabricante para con sus clientes respecto al 'efecto 2000' es un tema complejo y difícil. Me piden bastante información aquí sobre este tema.

Al final, creo que técnicamente no tendremos grandes problemas. Pero pagando, claro, pagando".

trujillofj@en.ono.es

"Como respuesta a la consulta de Tomàs Baiget," interviene Cristina Barragán: "la versión 98.1.0 de Vtls, que incluye la solución al problema del año 2000, se empezó a distribuir hace ya algunos meses entre nuestros usuarios.

En cuanto a la medida en que puede influir el efecto 2000 en los programas integrados de automatización de bibliotecas que no tengan solucionado el problema, se me ocurren de entrada diferentes aspectos, basándose en dos factores principalmente: ordenación (de entregas de revistas, de recordatorios de recepciones y reclamaciones, etc.) y cálculo de fechas (de períodos de préstamo, recepciones de publicaciones periódicas...).

Esto sería en líneas generales. Cada sistema presentaría variaciones en la problemática dependiendo de las características de cada módulo."

vtlscb@mail.cinet.es

Concha Ferrer, del Centro de Información Industrial y Patentes, del Instituto de la Mediana y Pequeña Industria Valenciana (Impiva) inicia su participación planteando algunas dudas surgidas al hilo de la intervención de Javier Trujillo: "No he entendido muy bien lo que ha querido decir Javier con su ejemplo de las fechas. No creo que los programas informáticos para aplicaciones documentales estén libres de lo que dicen los expertos. Según ellos el problema, entre otros, se plantea porque el campo fecha que fue definido con dos dígitos para el año, en aquellos programas que no lo hayan resuelto, plantearán verdaderos problemas. ¿Qué nos contestará la máquina cuando queramos recuperar referencias desde el año 1998 hasta el 2000, sabiendo que sólo tiene capacidad para los dos últimos dígitos? Es decir del 98 al 00 el resultado puede ser una operación fantástica, pero no creo que tengamos ningún documento válido. Bueno, todo esto suponiendo que nuestros programas no hayan resuelto el problema."

cferrer@super.medusa.es

Interviene de nuevo Javier Trujillo aclarando estas dudas: "Lo que señalaba en mi anterior correo no era más que una especie de 'alternativas chapuceras al campo fecha'. Como el tema del 'efecto 2000' no afecta a los campos numéricos ni de texto, se podrían poner las fechas como tales: '980.916' se leería como 16/09/98 y, si pones en un campo de texto libre '5 de enero del 2000', podrías recuperar ese documento buscando '5 and enero and 2000' en ese campo. Repito que esto es rizar el rizo, no vale para buscar entre fechas (en campos numéricos, sí) y no debe hacerse así, aunque por poder...

Por otra parte, no todas las bases de datos marcan el año con dos dígitos. Las que permitan introducir el año con cuatro dígitos no tienen por qué tener problemas con el año 2000. El problema es con los dos dígitos, y sobre todo, con las bases de datos que contengan registros con fechas anteriores al año 1901 o más antiguos (1800, 1700, etc.).

Desde luego, los que tengan sólo dos dígitos para el año sí que van a tener problemas, y la solución, repito, no es otra que rogar (si no exigir) al fabricante un 'parche' o actualización del programa para sobrevivir. Tampoco sabemos si el 'parche' funcionará de forma 'borrón y cuenta nueva' o si podremos importar nuestra base de datos de forma que actualice las fechas con cuatro dígitos para el año.

Por tanto, soluciones (por orden):

1. Actualizar el software de base (sistema operativo) a uno libre de errores (si no se tiene ya).
2. Contactar con el fabricante de nuestra base de datos y pedirle soluciones (gratis o baratas) para poder seguir usando su producto.
3. Partir nuestras bases de datos hasta el 31 de diciembre de 1999. Luego, empezar otras nuevas desde el 1 de enero del 2000. Estudiar con un programador la posibilidad de un programilla ad-hoc que nos permita realizar la misma búsqueda de forma paralela en las dos bases de datos (la anterior y la nueva).
4. Con una base de datos que no sufra ese problema, importar nuestros datos y modificar a mano todas las fechas de los registros a cuatro dígitos para el año. Hay programadores avispados que podrían hacernos un programilla que lo hiciera de forma automática (pero a ver a qué precio).
5. En último caso, no desesperar. Lo tienen peor los sistemas de control de tráfico aéreo y otros programas complejos. No llorar, mantener la calma. Otros muchos estarán como nosotros. Comprar un nuevo paquete con cinco dígitos para el año, para que en el año 10000 no tengamos el mismo problema.

Además, nos queda año y medio. Paciencia, que ya se les (nos) ocurrirá algo...".

trujillofj@en.ono.es

Para redondear la discusión, Josep Sau expone temas relacionados e igualmente problemáticos: "Atención al fin de time() en sistemas Unix, esperado para enero de 2038. Bastantes PCs, hasta aproximadamente 1995, incorporaban ROMs y relojes que no soportan el siglo que viene. Si se cambia la fecha del sistema a un año posterior a 1999, al reinicializar la máquina aparece la fecha 1 de enero de 1970. Otros temas relacionados para sufrir:

• La reaparición de los decimales en la contabilidad si/cuando se cambie al euro (o el nombre que tenga entonces).
• La necesidad de más cifras para los números telefónicos desde abril de 1998.
• La necesidad de actualizar algunos puntos del formato Marc, como la fecha de catalogación del registro, que se codifica con formato fijo aammdd en el campo 008.
• La necesidad de más cifras para el posible/futuro número único de identificación de ciudadano/clon europeo, la mitad de ellas cifras de control redundantes".

jsau@si.ges.ub.es

Aportando su propia experiencia Josep Manuel Rodríguez i Gairín dice: "En varias listas de distribución alguno de vosotros ha manifestado su preocupación sobre el efecto 2000 en los programas informáticos. Por lo que respecta a SOD (Gestión de un servicio de obtención de documentos) comentaros que el efecto 2000 está solucionado en la versión actual de web. SOD entiende las fechas de 4 cifras, y en las de dos cifras 'sabe' que todo lo anterior a 60 es del próximo milenio, y ordena correctamente y calcula los intervalos apropiados.

Un ejemplo:

Si accedéis a la demo:

http://www.kronosdoc.com/sodcgi/estadist.htm

y pedís estadísticas de 01/01/98 a 01/01/04 veréis que 'sabe' que os estáis refiriendo al 2004 no al 1904 igual que 'sabe' que estáis haciendo referencia a 1998 y no a 2098.

Las versiones de DOS no tienen este efecto aún solucionado, pero espero que para entonces todos los usuarios estén ya en web."

josep-m@bupc.upc.es

Nadie más se apuntó al debate. Sin embargo poco después llegó a nuestras manos el artículo de Anne Faulkner "The year 2000 problem and its implications for the information profession". Journal of Information Science, v. 24, n. 4, p. 255-265.

Resumen realizado para IWE por Cristina García Testal.

testal@uv.es

Enlace del artículo:
http://www.elprofesionaldelainformacion.com/contenidos/1998/diciembre/el_efecto_2000_y_las_bibliotecas.html