Microsoft y sus problemas de calendario III

Hoy termino la serie que empezó con la parte I y parte II.

Voy a poner otros cuatro productos de Microsoft con problemas de calendario, pero no quiero hacer sangre con esto. Todos los fabricantes han tenido problemas similares. La ventaja de centrarse en MS es que todo el mundo la conoce y que los casos se encuentran todavía hoy bien documentados aunque hayan pasado años en algunos casos.

Microsoft Exchange:

El Microsoft Exchange team anunció el 29 de febrero de 2008 lo siguiente:

Había llegado el 29-2-2008 y mucho clientes se pusieron en contacto con el Team porque:

1.-No se podían crear nuevos buzones.

2.-Las instalaciones de Exchange estaban fallando.

Comprobaron que el error se producía al intentar reiniciar el servicio "System Attendant" de Exchange 2007 el 29 de febrero de 2008.

Microsoft SharePoint:

Aparece un error cuando escriba 29 de febrero en el campo "Cumpleaños de" de SharePoint Server 2007.

Microsoft Outlook Web Access (OWA):

Convocatoria de reunión de 29 de febrero no funciona con Outlook Web Access asiático.

Microsoft Small Business Server:

El anuncio en la web oficial del 15 de enero de 2008 advertía que "The CEICW Certificate Generator will be out of the office on February 29, 2008".

Bueno, y eso es todo.

Y para que conste que el calculo de un año bisiesto es realmente fácil ahí va este código que la propia Microsoft nos pone a nuestra disposición:

Microsoft y sus problemas de calendario II

Ayer dejamos el tema en los problemas que tuvieron Windows95 y Windows98 con el año bisiesto 2000.

Pero hay más...

Si Windows95 y Windows98 eran los clientes más extendidos, en la parte servidora Windows NT4, lanzado en 1996, era el Rey de la jungla y requería la actualización por medio de un service pack para solucionar el problema del año bisiesto.

¿Y que hay del office?

El mayor problema con los documentos office y con las aplicaciones office no eran 100% responsabilidad de Microsoft.

A finales de 1999 cambié de trabajo y llegue a un sitio donde había aplicaciones enteras en Access (programación Visual Basic para Aplicaciones o VBA). Se utilizaba Access 2.0 y los campos de tipo fecha tenían años con 2 dígitos (Fecha corta). Si se hubieran utilizado los 4 dígitos no habría habido ningún problema pero no fue así.

El problema en Access 2.0 no es demasiado grave, pero la responsabilidad de Microsoft fue considerar en una suite de 1997 (office97) que el 00 era 1900 en lugar de 2000 (01 era 1901 y así hasta el final).

Bueno, la mayor parte de las aplicaciones seguían funcionando bien aunque el 00 se considerara 1900 (salvo si se utilizaban funciones para calcular diferencias entre fechas).

Migre las aplicaciones a Office97, cambié las fechas (código y datos) a años de 4 dígitos. Luego era necesario el Service Release 2 de Office97 y lógicamente antes del SR-2, el SR-1.

Bueno, a estas alturas algún avispado se habrá dado cuenta de un efecto colateral importante.

Si alguien hubiera seguido manejando fechas cortas (año de 2 dígitos), el Access por ejemplo consideraría que 00 se refiere al año 1900 en lugar del 2000. Y el año 2000 fue bisiesto y el 1900 no, por lo que en ese mismo Access el "29/2/00" habría provocado error de fecha incorrecta.

Pues eso no ocurrió, paradojas de la vida, por otro error de Microsoft. A todos los efectos, 1900 para Office es un año bisiesto por un problema de compatibilidad con Lotus 1-2-3:

Todavía me queda otro post en el que espero terminar el tema de los bisiestos. A ver si termino luego por la noche.

Nos vemos.

Microsoft y sus problemas de calendario

Hola amig@s,

Este post no es un ataque a Microsoft. No hay que entenderlo así. He utilizado sus sistemas operativos, aplicaciones y utilidades prácticamente durante toda la vida y hoy en día sigo utilizándolos a diario. Además, como se podrá ver a continuación, el soporte a las empresas y la documentación que proporcionan en caso de tener problemas es impresionante.

Lo que ocurre es que ahora que puedo recordarlo me gustaría recapitular un problema que tienen con los años bisiestos. Y es que no se qué les pasa. ¿Tan difícil es entenderlo? ¿Hay que introducir un tema exclusivo en todos los libros de programación?

Usted, desarrollador de paquetes comerciales, memorice esto de una vez. Si su aplicación maneja fechas, tiene que tener en cuenta los años bisiestos (esos que tienen 29 de febrero).


Bueno, sencillo ¿no? Está clarinete: Según el calendario gregoriano por el que nos regimos, un año es bisiesto si es divisible por 4, excepto el último de cada siglo (aquel divisible por 100), salvo que éste último sea divisible por 400.

Ejemplos típicos (por problemáticos): 1900 es divisible entre 4 pero no es bisiesto. 2000 es divisible entre 100 y es bisiesto.

Pues en el 2009, cincuenta años después del "FORTRAN Monitor System" seguimos con problemas de año bisiesto. Por favor, pónganse las pilas.

O sea, ¿que el firmware del cacharrín no se esperaba un día más en 2008? No se si reír o llorar pensando en esta noticia de unos pocos días antes...

Bueno, esto del submarino ha sido una pequeña broma.

Hagamos un poco de memoria,..., sí, esto yo lo he vivido antes..., poco antes del año 2000.

Resulta que aparte de todo el tema del efecto 2000, se daba otra circunstancia. El año 2000 era fin de siglo y normalmente no debería ser bisiesto, pero, que mala suerte, 2000 es múltiplo de 400 y por lo tanto, ES BISIESTO.

En aquella época previa al 2000 en las empresas había 2 sistemas operativos predominando en las empresas: windows 95 y windows 98. Tanto el 95 como el 98 ya requerían parche para el 2000, entre otras cosas por el tema del bisiesto.

Advertencia: Este problema del bisiesto en win95/98 es una anécdota sin importancia. Era más importante el problema del año 2000.

Documentación de microsoft para la actualización de Windows95:

ACTUALIZACIÓN WINDOWS 95 PARA EL EFECTO 2000  **********************************************************************  Microsoft Windows 95   Archivo LÉAME de la actualización para el año 2000  Marzo de 1999  ********************************************************************** Los siguientes problemas se resuelven al instalar la actualización. 1. Cuadro de diálogo Buscar "Archivos o carpetas" (shell32.dll)  La ficha Fecha de modificación del cuadro de diálogo Buscar "Archivos o carpetas" muestra el año en el formato AA. Este formato hace que los años posteriores al 2000 se aparezcan de forma incorrecta. Por ejemplo, si   escribe 20/03/2003, aparecerá 20/03/C3. Sin embargo, no tiene efecto alguno en la búsqueda. Si busca los archivos modificados en un intervalo de fechas concreto, escriba la fecha en formato de 2 o 4 dígitos y la búsqueda se realizará según las fechas escritas. El archivo se actualizará únicamente si utiliza la versión 950 o 950a de Windows 95. Este problema no se produce en versiones posteriores de Windows 95. 2. Administrador de archivos de Windows (winfile.exe)   El Administrador de archivos de Windows no muestra ni ordena correctamente las fechas posteriores al año 2000. Si utiliza el Administrador de archivos para ver el contenido de las carpetas y selecciona la vista "Todos los detalles del archivo", la fecha de los archivos creados en el año 2000 o posteriores aparecerán de la siguiente forma: 1 de enero de 2000 aparecerá como 1/1/;1  3 de febrero de 2023 aparecerá como 2/3/>3  5 de marzo de 2036 aparecerá como 3/5/=6 3. Intérprete de comandos (command.com)  El comando DATE (un comando interno de COMMAND.COM) no trata correctamente las fechas de dos dígitos entre 00 y 79. Si se escriben fechas de dos dígitos pertenecientes a este intervalo se produce un error "Fecha no válida". 4. Selector de fecha y hora (comctl32.dll).   Antes, cuando establecía la configuración regional en el Panel de control para que tratara los años con dos dígitos, la función Selector de fecha y hora no reflejaba correctamente esta fecha. Esta actualización corrige este problema. 5. Subprograma Marcador de teléfono (dialer.exe)  La opción Mostrar el registro de llamadas no muestra correctamente la fecha cuando una llamada telefónica finaliza correctamente. Si la fecha del sistema está ajustada al año 2000, se mostrará la fecha como 100,   101,102, etc.  Sucede, por ejemplo, cuando hace una llamada en el año 2000 con el subprograma Marcador. El archivo de registro creado o anexado al finalizar la conexión telefónica muestra incorrectamente la parte del año de la fecha de llamada: 101, 102, 103, etc. 6. Subprograma Fecha y hora del Panel de control (timedate.cpl)  Cuando se selecciona la fecha 29 de febrero y se cambia el año mediante las flechas arriba y abajo en el cuadro de diálogo Propiedades de Fecha y hora, el calendario mostrará 29 de febrero cada año, independientemente de si es un año bisiesto o no. Es un problema de presentación del subprograma. 7. Controlador virtual de DHCP (vdhcp.386)  Winipcfg /all - Las recuperaciones de direcciones IP obtenidas el 01/3/2000 o en una fecha posterior se considerarán como obtenidas el día anterior. La fecha del sistema se mostrará correctamente, pero el cliente de DHCP notificará como fecha el día anterior. Por ejemplo, si inicia una sesión en una LAN después del 1 de marzo del 2000 y ejecuta Winipcfg /all desde Inicio\Ejecutar o Ipconfig /all desde una sesión de DOS, la fecha de obtención es el día anterior. Después del 28/2/2000, la fecha de obtención es el día anterior a la fecha esperada. 8. Microsoft Foundation Class Library (mfc40.dll)  Es posible que, después del año 2000, los programas que utilicen los operadores integrados de la clase COleDateTime analicen incorrectamente las fechas. Por ejemplo, 02/05/2000 podría aparecer como 2/05/100. Microsoft ha modificado la clase COleDateTime para que sea menos sensible a las suposiciones de los   programas. 9. Comando Xcopy de DOS (xcopy.exe, xcopy32.exe)  Al usar xcopy en modo real con el parámetro opcional /D:fecha, xcopy no acepta años en formato de dos dígitos, excepto para el intervalo de años 80 a 99. Se mostrará el mensaje "Fecha no válida". Al usar xcopy en modo protegido (desde Windows), se aceptarán fechas de dos dígitos, pero se reconocerán como pertenecientes al siglo 20 (05/02/01 se verá como 05/02/1901). 10. Archivo de la biblioteca en tiempo de ejecución de Microsoft (msvcrt40.dll)   Algunas de las aplicaciones que utilizan esta biblioteca de tiempo de ejecución podrían comportarse como si fuera una hora antes de lo que indica el reloj de Windows. El problema durará una semana, del 1 de abril al 8 de abril del 2001, tras lo cual las aplicaciones cambian al horario de verano, lo que hará que vuelvan a estar sincronizadas con el sistema operativo.  El problema se debe a que el 1 de abril del 2001 es domingo, lo que provoca un pequeño error en un algoritmo del archivo de la biblioteca de tiempo de ejecución que comprueba el inicio del horario de verano.   En realidad, no se trata de un problema relacionado con el año 2000, sino con el horario de verano. Podría producirse en 1973, 1979, 1984, 1990, 2001, 2007, 2012, 2018, 2029 y 2035, todos ellos años en los que el 1 de abril es domingo. 11. Automatización OLE (oleaut32.dll, olepro32.dll, stdole2.tlb, asycfilt.dll)   La biblioteca de automatización de Microsoft contiene rutinas para interpretar los años de dos dígitos, y permite que las aplicaciones creen fechas no ambiguas.   En Windows 95 el punto de corte para los años que se indican con dos dígitos es 1999, lo que significa que 00 se interpretará como perteneciente al siglo 20. Por ejemplo 1/1/00 se convierte en 1/1/1900

En Windows98 el problema del bisiesto es idéntico a Windows95, aunque el resto de problemas del efecto 2000 es diferente. Lo realmente grave es que siendo un sistema operativo lanzado en 1998 tuviera tantos problemas para el 2000.

III. ¿Cuáles son los problemas relacionados con el milenio de Windows 98?

Los problemas mostrados a continuación se resuelven con la instalación 
de esta actualización.

1. Selector de fecha y hora (comctl32.dll). 
Antes, cuando establecía la configuración regional en el Panel de 
control para que tratara los años con dos dígitos, la función 
Selector de fecha y hora no reflejaba correctamente esta fecha. 
Esta revisión corrige este problema.

2. Microsoft Wallet (actpmnt.ocx)
Al escribir información de tarjetas de crédito en versiones de 
Microsoft Wallet anteriores a la versión 2.1.1383, debe escribir el 
mes, el día, y el año para las fechas de caducidad posteriores al 
año 2000. Si no lo hace, puede que no se trate la información de la 
forma esperada.

Por ejemplo, si escribe un número de tarjeta de crédito con una 
fecha de caducidad 01/5, se tratará como el 1 de mayo de año 
actual. Este comportamiento ha cambiado en Microsoft Wallet 
versión 2.1.1383 y en versiones posteriores.

3. Microsoft Virtual Machine
Se han notificado problemas relacionados con el milenio y con las 
máquinas virtuales de Java basadas en las versiones 1.1.1 a 1.1.5 
del Java Development Kit de Sun Microsystems. Puede que las 
aplicaciones programadas en Java que usan la biblioteca de clases 
java.txt.SimpleDateFormat traten incorrectamente las fechas de 4 
dígitos.

Por ejemplo, si tiene un subprograma o una aplicación programada en 
Java que usa SimpleDateFormat y escribe cuatro dígitos para el año, 
puede que las funciones de fecha trunquen el año y usen únicamente 
los dos primeros dígitos (por ejemplo, 2000 se convertiría en 20).

4. Subprograma Marcador de teléfono (dialer.exe)
La opción Mostrar el registro de llamadas no muestra correctamente 
la fecha cuando finaliza correctamente una llamada telefónica. Si 
la fecha del sistema está ajustada al año 2000, se mostrará la 
fecha como 100, 101,102, etc. 

Por ejemplo, cuando hace una llamada con el subprograma Marcador en 
el año 2000. El archivo de registro creado o anexado cuando 
finaliza la conexión telefónica muestra incorrectamente la parte 
del año de la fecha de llamada: 101, 102, 103, etc.

5. Subprograma de Fecha y hora (timedate.cpl)
Cuando selecciona la fecha 29 de febrero y cambia el año mediante 
las flechas arriba y abajo en el cuadro de diálogo Propiedades de 
Fecha y hora, el calendario mostrará 29 de febrero cada año, 
independientemente de si es un año bisiesto o no. Es un problema de 
presentación del subprograma.

6. Propiedades del documento (docprop.dll)
Cuando ve las propiedades de documentos de Microsoft WordPad o 
Microsoft Word y establece información de fecha personalizada, no 
se acepta el año 2000 como una entrada válida cuando se escribe 
como "00". Se supone que todas las fechas de dos dígitos están en 
el siglo 20 (es decir, 19xx). Además, si la zona horaria está 
establecida a Lejano Oriente, las propiedades de fecha pierden un 
día cuando escribe 2000 como año.

7. Inicio (io.sys)
Si se ha iniciado el sistema en el mismo momento en que la fecha 
del Reloj de tiempo real (RTC) pasa a medianoche, puede que el 
reloj del sistema muestra valores incorrectos para la fecha o la 
hora. Si reinicia el equipo se habrá solucionado este problema.

Por ejemplo, encienda el equipo y, a continuación, reinícielo en el 
mismo instante en que el reloj interno del sistema pasa de 
11:59:59 p.m. a 12:00:00 a.m. Puede que el sistema muestra un día o 
un año incorrectos hasta que se reinicie el equipo y se reinicie a 
su vez el reloj interno. Es un problema de comprobación y no está 
relacionado con el año 2000.

8. Controlador virtual de DHCP (vdhcp.386)
Winipcfg /all - Las direcciones IP obtenidas el 01/3/2000 o en una 
fecha posterior se considerarán como obtenidas el día anterior. La 
fecha del sistema se mostrará correctamente, pero el cliente de 
DHCP notificará como fecha el día anterior.

Por ejemplo, si conecta con una LAN después del 1 de marzo del 
2000, y ejecuta Winipcfg /all desde Inicio\Ejecutar o Ipconfig /all 
desde una sesión de DOS, la fecha de obtención es el día anterior. 
Después del 28/2/2000, la fecha de la dirección obtenida es el día 
anterior a la fecha esperada.

9. Microsoft Data Access (msdadc.dll, msadce.dll)
El archivo msdadc.dll forma parte de los componentes básicos de OLE 
DB y de Microsoft Data Access Components (MDAC). Si programa con 
ADO y sus recordsets de ADO incluyen tipos de datos de fecha, como 
adDate, adDBDate, adFileTime o adDBTimeStamp, y usa un formato de 
fecha que utiliza puntos como separador de fechas en lugar de 
barras (por ejemplo, 01.01.98 en lugar de 01/01/98), y especifica 
un año menos que 60, puede que la dll de conversión de datos 
(msdadc.dll) traduzca la fecha como una hora. Por ejemplo, puede 
que 01.01.01 (1 de enero de 2001) se convierta a 01:01:01 (30 de 
diciembre de 1899, 1:01:01 a.m.).

10. Microsoft Foundation Class Library (mfc40.dll)
Puede que después del año 2000, los programas que usan la función 
COleDateTime analicen incorrectamente una fecha. Para ver un 
ejemplo de esto después del año 2000, ejecute el archivo de 
información del sistema (msinfo32.exe) desde 
Programas\Accesorios\Herramientas del sistema y guarde el archivo. 
Abra este archivo de extensión .nfo y seleccione Propiedades en el 
menú Archivo. Puede que la marca de fecha muestra una fecha 
incorrecta. Por ejemplo, puede ver 05/02/2000 como 5/02/100.

11. Comando Xcopy de DOS (xcopy32.mod)
Al usar xcopy en modo real con el parámetro opcional /D:fecha, 
xcopy no acepta años en formato de dos dígitos, excepto para el 
intervalo de años 80 a 99. Se mostrará el mensaje "Fecha no 
válida". Al usar xcopy en modo protegido (desde Windows), se 
aceptarán fechas de dos dígitos, pero no se reconocerán como 
pertenecientes al siglo 20 (05/02/01 se verá como 05/02/1901).

El post de hoy me ha salido un poco largo, mañana continúo, y os aseguro que es sorprendente las veces que se ha repetido el error del bisiesto desde poco antes del 2000 hasta el 2009.

Saludos.