Controlar fechas y horas que incluyen DST

  • Artículo

En este artículo se describe cómo controlar las fechas y horas que incluyen el horario de verano (DST) y el efecto de los cambios de DST 2007 en determinados productos y tecnologías.

              Versión original del producto: Windows
Número de KB original: 932955

Resumen

Los desarrolladores que escriben aplicaciones que controlan fechas y horas pueden usar una o varias tecnologías que realizan la manipulación de fechas y la manipulación de hora. En concreto, ciertas API de sistema operativo base, el entorno de ejecución de C (CRT) y Microsoft .NET Framework pueden convertir o manipular fechas y horas. En este artículo se describen algunos de los conceptos generales que intervienen en el control de fechas y horas.

Almacenamiento y manipulación del tiempo

Las marcas de tiempo son valores que especifican una combinación de fecha y hora. Las aplicaciones que deben controlar las marcas de tiempo suelen almacenar esas marcas de tiempo en hora universal coordinada (UTC). La ventaja de UTC es que utc es universal. Las UTC no están sujetas a zonas horarias locales ni a DST. Sin embargo, las UTC no son fáciles de usar ni son relevantes para la mayoría de los usuarios. Aunque utc es la opción obvia para el almacenamiento, no es una buena opción para mostrar. Por lo tanto, la mayoría de las aplicaciones convierten la hora UTC a la hora local antes de mostrar la marca de tiempo al usuario. Por ejemplo, el Explorador de Windows aplica la zona horaria y la configuración de DST a la marca de tiempo UTC antes de que muestre las fechas y horas de los archivos de un directorio de New Technology File System (NTFS).

La conversión de la hora UTC a la hora local se puede considerar como la aplicación de dos desplazamientos. El primero es el desplazamiento de zona horaria y el segundo es el desplazamiento DST. Por lo tanto, la hora local es realmente hora UTC más un desplazamiento de zona horaria, además de cualquier desplazamiento de DST aplicable. El desplazamiento de zona horaria es bastante sencillo. El equipo está configurado para una zona horaria determinada y esa zona horaria tiene un desplazamiento con respecto a utc. Determinar si se debe aplicar un desplazamiento DST es mucho más complejo. Esta actividad se basa en muchas reglas complejas y dinámicas.

Estas reglas de DST complejas han cambiado recientemente con DST 2007. A partir de 2007, el Estados Unidos ha adoptado nuevas fechas de inicio y nuevas fechas de finalización para DST. Además, es habitual que otros países o regiones y gobiernos cambien de forma rutinaria las fechas de inicio y las fechas de finalización del DST en zonas horarias que están bajo su control. En la sección siguiente se describen los efectos del cambio de DST 2007 en los productos relacionados con los desarrolladores.

Para obtener más información sobre DST 2007, consulte Ayuda y soporte técnico para el horario de verano.

Efectos de DST 2007 en Windows

En Windows Update y en Microsoft Update, hay actualizaciones disponibles que permiten a Windows aplicar correctamente los cambios para DST 2007 y para los años siguientes. Una vez aplicadas estas actualizaciones, Windows calcula correctamente los desplazamientos actuales de la hora UTC a la hora local a medida que el equipo pasa por DST. Los desplazamientos incluyen los desplazamientos de las API base y de las API relacionadas con el tiempo de red.

Para obtener más información, vea Actualización de zona horaria acumulativa de diciembre de 2007 para sistemas operativos Windows.

Efectos de DST 2007 en el entorno de ejecución de C (CRT)

CRT también realiza traducciones de fechas y traducciones de hora. Por lo tanto, CRT también debe actualizarse para incluir las nuevas reglas para DST 2007. CRT realiza su propio control de tiempo solo cuando se establece la variable de entorno TZ o cuando se produce un error en una llamada de tiempo de API del sistema operativo subyacente. Novedades están disponibles para las CRT que se incluyen con cada versión de Visual Studio y también para las CRT que se incluyen con Windows. Estas actualizaciones permiten que CRT siga controlando correctamente las conversiones de DST en Estados Unidos zonas horarias.

Efectos de DST 2007 en .NET Framework

.NET Framework se basa en las llamadas al sistema operativo subyacente. Por lo tanto, el comportamiento de .NET Framework refleja el estado del sistema operativo subyacente. No se requiere ninguna actualización independiente.

Efectos de DST 2007 en los IDE de .NET de Visual Studio

Los entornos de desarrollo integrado (IDE) de Visual Studio .NET incluyen las versiones 2002, 2003 y 2005 de Visual C++, Visual C# y Visual Basic. Estos productos solo se ven afectados porque incluyen CRT. No se requiere ninguna actualización específica del IDE.

Efectos de DST 2007 en Visual Studio 2005 Team Foundation Server

Visual Studio 2005 Team Foundation Server se basa en el sistema operativo subyacente para las conversiones de fecha y hora. Por lo tanto, Visual Studio 2005 Team Foundation Server muestra el mismo comportamiento que el sistema operativo. Visual Studio 2005 Team Foundation Server también se basa en SQL Server, SQL Server Reporting Services y Windows SharePoint Services. Los equipos deben actualizarse con las actualizaciones pertinentes para el sistema operativo, para SQL Server y para Windows SharePoint Services. Todas las actualizaciones pertinentes se deben aplicar a todos los equipos afectados al mismo tiempo. No se requiere ninguna actualización independiente de Visual Studio 2005 Team Foundation Server.

Efectos de DST 2007 en Visual Studio 2005 Team System

Visual Studio 2005 Team System se ve afectado a través del sistema operativo, a través de Visual Studio 2005 Team Foundation Server y a través de CRT. No se requiere ninguna actualización independiente de Visual Studio 2005 Team System.

Efectos de DST 2007 en el entorno de ejecución de Visual Basic 6.0

El entorno de ejecución de Visual Basic 6.0 no se ve afectado.

Efectos de DST 2007 en Visual C++ 6.0

Visual C++ 6.0 ya no se admite. Para obtener más información, consulte la Directiva de ciclo de vida de Microsoft.

Efectos de DST 2007 en Windows SDK para Windows Vista

Este kit de desarrollo de software (SDK) incluye una versión de CRT que se ve afectada por los cambios de DST 2007. Como parte de la instalación de este SDK, puede instalar CRT de Visual Studio 2005 en equipos que aún no tengan instalada esa versión de CRT. Si ya está instalada una versión más reciente de CRT, la instalación del SDK no sobrescribirá esa versión más reciente. Cuando se desinstala el SDK, la versión más reciente de CRT se deja en el equipo. Puede instalar la actualización crt de Visual Studio 2005 antes o después de instalar el SDK.

Windows SDK para Windows Vista también instala un conjunto de módulos de combinación (archivos .msm) para CRT de Visual Studio 2005 para la redistribución de CRT como parte de aplicaciones personalizadas de C++. Una aplicación que implemente CRT redistribuible en la carpeta de instalación de la aplicación debe implementar crt actualizado desde la actualización de CRT de Visual Studio 2005 en lugar de los archivos .msm de CRT del SDK de Windows para Windows Vista. Una aplicación que implemente la actualización de CRT redistribuible de Visual Studio 2005 en la carpeta de instalación de Windows debe aplicar la actualización redistribuible de CRT de Visual Studio 2005 a esos equipos.

Efectos de DST 2007 en el SDK de la plataforma para Windows Server 2003 R2

Este SDK incluye una versión de CRT que se ve afectada por los cambios de DST 2007. Los clientes deben seguir las notas de la versión de este SDK y usar las actualizaciones de CRT de Visual Studio 2005 si son necesarias.

Efectos de DST 2007 en el SDK de .NET Framework 2.0

Este SDK incluye una versión de CRT que se ve afectada por los cambios de DST 2007. Como parte de la instalación de este SDK, puede instalar CRT de Visual Studio 2005 en equipos que aún no tengan instalada esa versión de CRT. Si ya está instalada una versión más reciente de CRT, la instalación del SDK no sobrescribirá esa versión más reciente. Cuando se desinstala el SDK, la versión más reciente de CRT se deja en el equipo. Puede instalar la actualización crt de Visual Studio 2005 antes o después de instalar el SDK.

Conversión de hora local en Windows

Las aplicaciones suelen convertir las horas UTC en horas locales antes de mostrar información de hora e información de fecha al usuario. Windows proporciona varias API para que las aplicaciones las usen para la manipulación de marcas de tiempo.

  • La GetSystemTime() función y la GetSystemTimeAsFileTime() función obtienen la hora UTC actual en una SYSTEMTIME estructura o en una FILETIME estructura.

  • La GetLocalTime() función obtiene la hora local actual en una SYSTEMTIME estructura.

  • La GetTimeZoneInformation() función obtiene una TIME_ZONE_INFORMATION estructura que describe la zona horaria actual y la configuración DST del equipo.

  • La SystemTimeToFileTime() función y la serialización de funciones FileTimeToSystemTime() entre SYSTEMTIME estructuras y FILETIME estructuras.

  • La FileTimeToLocalFileTime() función y la LocalFileTimeToFileTime() función convierten y traducen una FILETIME estructura entre utc y hora local mediante la zona horaria actual y la configuración de DST en el equipo.

  • La SystemTimeToTzSpecificLocalTime() función y la TzSpecificTimeToSystemTime() función convierten una marca de tiempo UTC en una SYSTEMTIME estructura en una estructura local SYSTEMTIME . Estas funciones usan una TIME_ZONE_INFORMATION estructura que especifica la fecha de inicio y la fecha de finalización de DST. De forma predeterminada, las reglas de DST actuales se usan cuando no se proporciona dicha estructura.

  • La NetRemoteTOD() función obtiene la hora de un servidor remoto mediante la información y la configuración del servidor.

Nota:

La FileTimeToLocalFileTime() función y la LocalFileTimeToFileTime() función realizan la conversión entre la hora UTC y la hora local utilizando solo la información de zona horaria actual y la información de DST. Esta conversión se produce independientemente de la marca de tiempo que se va a convertir.

Para ver un ejemplo de este comportamiento en el Explorador de Windows, siga estos pasos en un equipo que reside en una zona horaria que usa DST.

Estos pasos requieren que cambie el reloj del sistema. Por lo tanto, debe salir de cualquier aplicación, como las aplicaciones de calendario, que pueda reaccionar a estos cambios de tiempo antes de seguir estos pasos.

  1. Cambie la fecha del equipo a un día DST. Por ejemplo, establezca la fecha en 1 de julio de 2006.
  2. En un directorio NTFS del mismo equipo, cree un nuevo archivo de texto denominado Test.txt.
  3. Observe que la marca de tiempo del archivo se muestra de la siguiente manera en el Explorador de Windows:
    1/7/2006 15:37
  4. Cambie la fecha del equipo a un día que no es DST. Por ejemplo, establezca la fecha en 1 de febrero de 2007.
  5. Actualice la ventana del Explorador de Windows.
  6. Observe que la marca de tiempo del archivo se muestra de la siguiente manera en el Explorador de Windows:
    1/7/2006 2:37 p.m.

En este ejemplo anterior, la marca de tiempo UTC del archivo no cambia. Sin embargo, las reglas que se usan para convertir la marca de tiempo en un cambio de hora local en función de la fecha actual en el equipo. En el paso 3, se aplicó un desplazamiento DST porque el 1 de julio se encuentra dentro del intervalo DST. En el paso 6, no se aplicó ningún desplazamiento DST, ya que el 1 de febrero no se encuentra dentro del intervalo DST. Este comportamiento se produce para que la marca de tiempo del archivo se pueda convertir de forma determinista a la hora local y a la hora local.

El SystemTimeToTzSpecificLocalTime() método y el TzSpecificTimeToSystemTime() método convierten entre la hora UTC y la hora local mediante la estructura proporcionada TIME_ZONE_INFORMATION . Si no se proporciona información de zona horaria, estas funciones usan las reglas de zona horaria actuales y las reglas de DST para determinar si se debe aplicar un desplazamiento DST a la marca de tiempo. Esto equivale funcionalmente a llamar al GetTimeZoneInformation() método para obtener la TIME_ZONE_INFORMATION estructura que está actualmente en vigor.

La TIME_ZONE_INFORMATION estructura incluye la fecha de inicio y la fecha de detención para DST. Por lo tanto, cuando la TIME_ZONE_INFORMATION estructura usa la información de zona horaria actual, la TIME_ZONE_INFORMATION estructura puede introducir una imprecisión histórica. Este comportamiento puede producirse si la información de zona horaria actual y la información de DST no reflejan la marca de tiempo que se va a convertir. Este comportamiento solo se ve afectado por DST 2007 porque se han cambiado las reglas que rigen las fechas en que se inicia y detiene DST.

Para obtener conversiones históricamente precisas de estas funciones, una aplicación debe proporcionar una estructura históricamente precisa TIME_ZONE_INFORMATION cuando la aplicación llama a estas funciones.

Zonas horarias dinámicas en Windows

Windows Vista presenta zonas horarias DST dinámicas. DST dinámico proporciona compatibilidad con zonas horarias cuyos límites para DST cambian de año a año. Estas reglas se almacenan en el Registro. Las aplicaciones pueden consultar las reglas mediante la GetDynamicTimeZoneInformation() función .

Las zonas horarias dinámicas permiten una actualización más sencilla de los equipos, especialmente para las configuraciones regionales en las que los límites anuales de DST se conocen de antemano. Para obtener más información sobre la DYNAMIC_TIME_ZONE_INFORMATION estructura en Windows SDK para Vista, consulte DYNAMIC_TIME_ZONE_INFORMATION estructura.

Conversión de hora local en el entorno de ejecución de C (CRT)

CRT básicamente tiene tres modos en los que puede traducir marcas de tiempo:

  • Si no se establece la variable de entorno TZ, CRT llama a las API de Windows y muestra el comportamiento de Windows como se describe en este artículo.

  • Si se establece la variable de entorno TZ, CRT realiza sus propias conversiones basadas en esa configuración. CRT se está actualizando para que respete las nuevas reglas de DST 2007 cuando realiza conversiones en este escenario.

  • Si no se establece la variable de entorno TZ, pero se produce un error en las API de Windows subyacentes, CRT vuelve a sus propias conversiones mediante el uso de un valor de PST8PDT para la variable de entorno TZ.

CRT contiene su propia lógica para convertir utc a hora local. Las aplicaciones pueden obtener marcas de tiempo UTC de funciones como la time() función . Estas marcas de tiempo UTC se almacenan en time_t valores. La conversión a la hora local se puede realizar con una función como la localtime_s() función . La localtime_s() función rellena una tm estructura definida en el archivo de Time.h encabezado. La tm estructura se basa en la zona horaria definida en la variable de entorno TZ y en las reglas DST que están en vigor en el momento de la marca de tiempo.

Nota:

Esta conversión sigue las reglas específicas de la Estados Unidos.

Antes de aplicar la actualización DST 2007, CRT controla correctamente las marcas de tiempo actuales en Estados Unidos zonas horarias. Después de aplicar la actualización DST 2007, CRT también controla las fechas Estados Unidos pasadas y futuras. Novedades de CRT se enumeran en la sección Referencias.

Conversión de hora local en .NET Framework

.NET Framework contiene clases que almacenan y convierten marcas de tiempo. Estas clases incluyen la DateTime clase , la TimeZone clase , la TimeSpan clase y la DateTimeKind clase . Como se indicó anteriormente, estas clases dependen principalmente de la implementación de la plataforma subyacente. Estas clases muestran el mismo comportamiento que las API del sistema operativo subyacente.

Un comportamiento interesante mostrado por las clases de fecha y hora de .NET Framework se relaciona con las funciones que desplazan la marca de tiempo en una cantidad solicitada. Por ejemplo, considere la AddHours() función, la AddMinutes() función y la AddSeconds() función de la DateTime clase . Estas funciones, y las funciones con nombre similar, simplemente incrementan la marca de tiempo en la cantidad solicitada sin tener en cuenta la configuración de DST. Este comportamiento podría considerarse aritmética simple en la marca de tiempo UTC subyacente. Sin embargo, este comportamiento podría dar lugar a resultados inesperados cuando la adición hace que la marca de tiempo pase dentro o fuera de DST. Este comportamiento no está relacionado con los cambios de DST 2007.

Recomendaciones

Las siguientes recomendaciones pueden ayudar a los desarrolladores a minimizar el efecto de DST 2007 y a mejorar el control general de fecha y hora.

  • Debe planear una instalación casi atómica de las actualizaciones de DST 2007. Todas las actualizaciones de DST 2007 planeadas se deben aplicar lo más cerca posible entre sí. Si un equipo que se ha actualizado intenta usar métodos como consultas SQL o servicios web para comunicarse con un equipo que no se ha actualizado, pueden producirse errores de traducción. De forma similar, si un solo equipo requiere dos o más actualizaciones, como La actualización de Windows y la actualización de CRT, las actualizaciones se deben aplicar al mismo tiempo.

  • Las marcas de tiempo UTC son históricamente precisas. Normalmente es la conversión a la hora local la que afecta a la mayoría de las aplicaciones. Las aplicaciones siempre deben almacenar marcas de tiempo UTC. Las conversiones a la hora local con fines de visualización requieren información de zona horaria e información de DST. Esta información puede proceder de varios orígenes:

    • La aplicación puede usar la zona horaria actual y la configuración de DST para la conversión. Esto puede introducir una imprecisión en la conversión si la zona horaria actual y la configuración de DST no estaban en vigor en el momento de la marca de tiempo.

    • La aplicación puede almacenar la información de zona horaria y la información de DST previamente precisas, además de la marca de tiempo UTC.

    • Cuando hay zonas horarias dinámicas disponibles, la aplicación puede usar zonas horarias dinámicas para determinar qué información de zona horaria se debe aplicar a una marca de tiempo UTC determinada. Esta opción solo está disponible cuando la información de zona horaria dinámica está disponible para una marca de tiempo específica y para una zona horaria específica.

    • La aplicación puede almacenar una marca de tiempo local y la marca de tiempo UTC. Este método evita la necesidad de una conversión futura.

  • Cualquier comunicación entre equipos que traten con marcas de tiempo debe usar marcas de tiempo UTC. Esto proporciona implícitamente a ambos equipos la misma información de contexto para UTC.

  • Si una aplicación controla las fechas, debe tener cuidado con la forma en que las fechas se controlan en las pruebas. Las fechas que se muestran sin información de hora se almacenan normalmente como una marca de tiempo de 12:00 a.m. en la fecha pertinente. Por lo tanto, un error off-by-one en la parte de hora de la marca de tiempo podría dar lugar a un resultado off-by-one en la fecha efectiva si la hora se desplaza a las 11:00 p.m. del día anterior.

Referencias