Gérer les dates et heures qui incluent l’heure d’été

  • Article

Cet article explique comment gérer les dates et heures qui incluent l’heure d’été (HEURE d’été) et l’effet des changements DST 2007 sur certains produits et technologies.

              Version d’origine du produit : Windows
Numéro de la base de connaissances d’origine : 932955

Résumé

Les développeurs qui écrivent des applications qui gèrent des dates et des heures peuvent utiliser une ou plusieurs technologies qui effectuent la manipulation de date et d’heure. En particulier, certaines API de système d’exploitation de base, le runtime C (CRT) et Microsoft .NET Framework peuvent convertir ou manipuler des dates et des heures. Cet article décrit certains des concepts généraux impliqués dans la gestion des dates et des heures.

Stockage et manipulation de l’heure

Les horodatages sont des valeurs qui spécifient une combinaison de date et d’heure. Les applications qui doivent gérer les horodatages stockent généralement ces horodatages en temps universel coordonné (UTC). L’avantage d’UTC est que l’UTC est universel. L’heure UTC n’est pas soumise aux fuseaux horaires locaux ni à l’heure d’été. Toutefois, l’utc n’est pas convivial ni pertinent pour la plupart des utilisateurs. Bien que l’utc soit le choix évident pour le stockage, il n’est pas un bon choix pour l’affichage. Par conséquent, la plupart des applications convertissent l’heure UTC en heure locale avant d’afficher l’horodatage à l’utilisateur. Par exemple, Windows Explorer applique le fuseau horaire et le paramètre DST au timestamp UTC avant d’afficher les dates et heures des fichiers dans un répertoire NTFS (New Technology File System).

La conversion de l’heure UTC en heure locale peut être considérée comme l’application de deux décalages. Le premier est le décalage de fuseau horaire et le second est le décalage d’heure d’été. Par conséquent, l’heure locale est en fait l’heure UTC plus un décalage de fuseau horaire, plus tout décalage DST applicable. Le décalage de fuseau horaire est assez simple. L’ordinateur est configuré pour un fuseau horaire particulier, et ce fuseau horaire a un décalage par rapport à UTC. Déterminer si un décalage DST doit être appliqué est beaucoup plus complexe. Cette activité s’appuie sur de nombreuses règles complexes et dynamiques.

Ces règles complexes d’été ont récemment changé avec la DST 2007. Depuis 2007, le États-Unis a adopté de nouvelles dates de début et de fin pour l’heure d’été. En outre, il est courant que d’autres pays/régions et gouvernements modifient systématiquement les dates de début et de fin de l’heure d’été dans les fuseaux horaires qui sont sous leur contrôle. La section suivante décrit les effets de la modification DST 2007 sur les produits liés aux développeurs.

Pour plus d’informations sur DST 2007, consultez Aide et support de l’heure d’été.

Effets DST 2007 sur Windows

Sur Windows Update et sur Microsoft Update, des mises à jour sont disponibles qui permettent à Windows d’appliquer correctement les modifications pour DST 2007 et pour les années suivantes. Une fois ces mises à jour appliquées, Windows calcule correctement les décalages actuels entre l’heure UTC et l’heure locale à mesure que l’ordinateur passe par l’heure d’été. Les décalages incluent les décalages pour les API de base et pour les API liées au temps de mise en réseau.

Pour plus d’informations, consultez Mise à jour cumulative du fuseau horaire de décembre 2007 pour les systèmes d’exploitation Windows.

Effets DST 2007 sur le runtime C (CRT)

Le CRT effectue également des traductions de date et d’heure. Par conséquent, le CRT doit également être mis à jour pour inclure les nouvelles règles pour l’heure d’été 2007. Le CRT effectue sa propre gestion de l’heure uniquement lorsque la variable d’environnement TZ est définie ou lorsqu’un appel d’heure d’API du système d’exploitation sous-jacent échoue. Mises à jour sont disponibles pour les fichiers CRT inclus dans chaque version de Visual Studio, ainsi que pour les crts fournis avec Windows. Ces mises à jour permettent au CRT de continuer à gérer correctement les conversions d’heure d’été dans États-Unis fuseaux horaires.

Effets de DST 2007 sur le .NET Framework

Le .NET Framework s’appuie sur les appels de système d’exploitation sous-jacents. Par conséquent, le comportement du .NET Framework reflète l’état du système d’exploitation sous-jacent. Aucune mise à jour distincte n’est requise.

Effets DST 2007 sur les IDE Visual Studio .NET

Les environnements de développement intégré (IDE) Visual Studio .NET incluent les versions 2002, 2003 et 2005 de Visual C++, Visual C# et Visual Basic. Ces produits sont affectés uniquement parce qu’ils incluent le CRT. Aucune mise à jour spécifique à l’IDE n’est requise.

Effets DST 2007 sur Visual Studio 2005 Team Foundation Server

Visual Studio 2005 Team Foundation Server s’appuie sur le système d’exploitation sous-jacent pour les conversions de date et d’heure. Par conséquent, Visual Studio 2005 Team Foundation Server présente le même comportement que le système d’exploitation. Visual Studio 2005 Team Foundation Server s’appuie également sur SQL Server, SQL Server Reporting Services et Windows SharePoint Services. Les ordinateurs doivent être mis à jour avec les mises à jour appropriées pour le système d’exploitation, pour SQL Server et pour Windows SharePoint Services. Toutes les mises à jour pertinentes doivent être appliquées simultanément sur tous les ordinateurs concernés. Aucune mise à jour distincte de Visual Studio 2005 Team Foundation Server n’est requise.

Effets DST 2007 sur Visual Studio 2005 Team System

Visual Studio 2005 Team System est affecté par le biais du système d’exploitation, de Visual Studio 2005 Team Foundation Server et du CRT. Aucune mise à jour distincte de Visual Studio 2005 Team System n’est requise.

Effets DST 2007 sur le runtime Visual Basic 6.0

Le runtime Visual Basic 6.0 n’est pas affecté.

Effets DST 2007 sur Visual C++ 6.0

Visual C++ 6.0 n’est plus pris en charge. Pour plus d’informations, consultez la politique de support Microsoft.

Effets DST 2007 sur le SDK Windows pour Windows Vista

Ce Kit de développement logiciel (SDK) inclut une version du CRT qui est affectée par les modifications apportées à DST 2007. Dans le cadre de l’installation de ce Kit de développement logiciel (SDK), vous pouvez installer Visual Studio 2005 CRT sur les ordinateurs sur lesquels cette version du CRT n’est pas déjà installée. Si une version plus récente du CRT est déjà installée, l’installation du Kit de développement logiciel (SDK) ne remplace pas cette version plus récente. Lorsque le KIT de développement logiciel (SDK) est désinstallé, la dernière version de CRT est laissée sur l’ordinateur. Vous pouvez installer la mise à jour CRT de Visual Studio 2005 avant ou après l’installation du Kit de développement logiciel (SDK).

Le SDK Windows pour Windows Vista installe également un ensemble de modules de fusion (fichiers .msm) pour visual Studio 2005 CRT pour la redistribution du CRT dans le cadre d’applications C++ personnalisées. Une application qui déploie le CRT redistribuable dans le dossier d’installation de l’application doit déployer le CRT mis à jour à partir de la mise à jour CRT de Visual Studio 2005 au lieu des fichiers .msm CRT du Kit de développement logiciel (SDK) Windows pour Windows Vista. Une application qui déploie la mise à jour redistribuable De Visual Studio 2005 CRT dans le dossier d’installation windows doit appliquer la mise à jour redistribuable crt visual studio 2005 à ces ordinateurs.

Effets DST 2007 sur le SDK de plateforme pour Windows Server 2003 R2

Ce Kit de développement logiciel (SDK) inclut une version du CRT qui est affectée par les modifications apportées à DST 2007. Les clients doivent suivre les notes de publication de ce Kit de développement logiciel (SDK) et utiliser les mises à jour CRT de Visual Studio 2005 si nécessaire.

Effets de DST 2007 sur le Kit de développement logiciel (SDK) .NET Framework 2.0

Ce Kit de développement logiciel (SDK) inclut une version du CRT qui est affectée par les modifications apportées à DST 2007. Dans le cadre de l’installation de ce Kit de développement logiciel (SDK), vous pouvez installer Visual Studio 2005 CRT sur les ordinateurs sur lesquels cette version du CRT n’est pas déjà installée. Si une version plus récente du CRT est déjà installée, l’installation du KIT de développement logiciel (SDK) ne remplace pas cette version plus récente. Lorsque le KIT de développement logiciel (SDK) est désinstallé, la dernière version de CRT est laissée sur l’ordinateur. Vous pouvez installer la mise à jour CRT de Visual Studio 2005 avant ou après l’installation du Kit de développement logiciel (SDK).

Conversion d’heure locale dans Windows

Les applications convertissent généralement les heures UTC en heures locales avant d’afficher des informations d’heure et de date à l’utilisateur. Windows fournit plusieurs API que les applications peuvent utiliser pour la manipulation d’horodatage.

  • La GetSystemTime() fonction et la GetSystemTimeAsFileTime() fonction obtiennent l’heure UTC actuelle dans une SYSTEMTIME structure ou dans une FILETIME structure.

  • La GetLocalTime() fonction obtient l’heure locale actuelle dans une SYSTEMTIME structure.

  • La GetTimeZoneInformation() fonction obtient une TIME_ZONE_INFORMATION structure qui décrit le fuseau horaire actuel et le paramètre DST pour l’ordinateur.

  • La SystemTimeToFileTime() fonction et la FileTimeToSystemTime() fonction marshalent entre SYSTEMTIME les structures et FILETIME les structures.

  • La FileTimeToLocalFileTime() fonction et la LocalFileTimeToFileTime() fonction convertissent et traduisent une FILETIME structure entre l’heure UTC et l’heure locale à l’aide du fuseau horaire actuel et du paramètre DST sur l’ordinateur.

  • La SystemTimeToTzSpecificLocalTime() fonction et la TzSpecificTimeToSystemTime() fonction convertissent un horodatage UTC dans une SYSTEMTIME structure en structure locale SYSTEMTIME . Ces fonctions utilisent une TIME_ZONE_INFORMATION structure qui spécifie la date de début et la date de fin de l’heure d’été. Par défaut, les règles d’heure d’été actuelles sont utilisées lorsqu’aucune structure de ce type n’est fournie.

  • La NetRemoteTOD() fonction obtient l’heure d’un serveur distant à l’aide des informations et des paramètres du serveur.

Remarque

La FileTimeToLocalFileTime() fonction et la LocalFileTimeToFileTime() fonction effectuent la conversion entre l’heure UTC et l’heure locale en utilisant uniquement les informations de fuseau horaire actuel et les informations d’heure d’été. Cette conversion se produit quel que soit l’horodatage en cours de conversion.

Pour voir un exemple de ce comportement dans Windows Explorer, suivez ces étapes sur un ordinateur qui se trouve dans un fuseau horaire qui utilise l’heure d’été.

Pour effectuer ces étapes, vous devez modifier l’horloge système. Par conséquent, vous devez quitter toutes les applications, telles que les applications de calendrier, qui peuvent réagir à ces changements d’heure avant de suivre ces étapes.

  1. Remplacez la date sur l’ordinateur par un jour d’heure d’été. Par exemple, définissez la date sur 1er juillet 2006.
  2. Dans un répertoire NTFS sur le même ordinateur, créez un fichier texte nommé Test.txt.
  3. Notez que l’horodatage sur le fichier s’affiche comme suit dans Windows Explorer :
    1/7/2006 15 :37
  4. Remplacez la date sur l’ordinateur par un jour autre que l’heure d’été. Par exemple, définissez la date sur 1er février 2007.
  5. Actualisez la fenêtre Windows Explorer.
  6. Notez que l’horodatage sur le fichier s’affiche comme suit dans Windows Explorer :
    1/07/2006 14 :37

Dans cet exemple précédent, l’horodatage UTC sur le fichier ne change pas. Toutefois, les règles utilisées pour convertir l’horodatage en heure locale changent en fonction de la date actuelle sur l’ordinateur. À l’étape 3, un décalage d’heure d’été a été appliqué, car le 1er juillet se situe dans la plage de l’heure d’été. À l’étape 6, aucun décalage d’heure d’été n’a été appliqué, car le 1er février ne fait pas partie de la plage DST. Ce comportement se produit afin que l’horodatage du fichier puisse être converti de manière déterministe en heure locale et à partir de l’heure locale.

La SystemTimeToTzSpecificLocalTime() méthode et la méthode effectuent une TzSpecificTimeToSystemTime() conversion entre l’heure UTC et l’heure locale à l’aide de la structure fournie TIME_ZONE_INFORMATION . Si aucune information de fuseau horaire n’est fournie, ces fonctions utilisent les règles de fuseau horaire actuelles et les règles d’heure d’été pour déterminer si un décalage DST doit être appliqué à l’horodatage. Cela équivaut fonctionnellement à appeler la GetTimeZoneInformation() méthode pour obtenir la TIME_ZONE_INFORMATION structure actuellement en vigueur.

La TIME_ZONE_INFORMATION structure inclut la date de début et la date d’arrêt de l’heure d’été. Par conséquent, lorsque la TIME_ZONE_INFORMATION structure utilise les informations actuelles du fuseau horaire, la TIME_ZONE_INFORMATION structure peut introduire une inexactitude historique. Ce comportement peut se produire si les informations de fuseau horaire actuelles et les informations d’heure d’été ne reflètent pas l’horodatage en cours de conversion. Ce comportement est affecté par DST 2007 uniquement parce que les règles qui régissent les dates de début et d’arrêt de l’heure d’été ont été modifiées.

Pour obtenir des conversions historiquement précises à partir de ces fonctions, une application doit fournir une structure historiquement précise TIME_ZONE_INFORMATION lorsque l’application appelle ces fonctions.

Fuseaux horaires dynamiques dans Windows

Windows Vista introduit des fuseaux horaires DST dynamiques. L’heure d’été dynamique prend en charge les fuseaux horaires dont les limites pour l’heure d’été changent d’une année à l’autre. Ces règles sont stockées dans le Registre. Les applications peuvent interroger les règles à l’aide de la GetDynamicTimeZoneInformation() fonction .

Les fuseaux horaires dynamiques facilitent la mise à jour des ordinateurs, en particulier pour les paramètres régionaux où les limites annuelles de l’heure d’été sont connues à l’avance. Pour plus d’informations sur la DYNAMIC_TIME_ZONE_INFORMATION structure du Kit de développement logiciel (SDK) Windows pour Vista, consultez structure DYNAMIC_TIME_ZONE_INFORMATION.

Conversion d’heure locale dans le runtime C (CRT)

Le CRT a essentiellement trois modes dans lesquels il peut traduire les horodatages :

  • Si la variable d’environnement TZ n’est pas définie, le CRT appelle les API Windows et présente le comportement Windows comme décrit dans cet article.

  • Si la variable d’environnement TZ est définie, le CRT effectue ses propres conversions basées sur ce paramètre. Le CRT est en cours de mise à jour afin de respecter les nouvelles règles DST 2007 lorsqu’il effectue des conversions dans ce scénario.

  • Si la variable d’environnement TZ n’est pas définie, mais que les API Windows sous-jacentes échouent, le CRT revient à ses propres conversions en utilisant la valeur PST8PDT pour la variable d’environnement TZ.

Le CRT contient sa propre logique pour convertir l’heure UTC en heure locale. Les applications peuvent obtenir des horodatages UTC à partir de fonctions telles que la time() fonction . Ces horodatages UTC sont stockés dans des time_t valeurs. La conversion en heure locale peut être effectuée avec une fonction telle que la localtime_s() fonction . La localtime_s() fonction remplit une tm structure définie dans le fichier d’en-tête Time.h . La tm structure est basée sur le fuseau horaire défini dans la variable d’environnement TZ et sur les règles DST qui sont en vigueur au moment de l’horodatage.

Remarque

Cette conversion suit des règles spécifiques au États-Unis.

Avant d’appliquer la mise à jour DST 2007, le CRT gère correctement les horodatages actuels dans États-Unis fuseaux horaires. Après avoir appliqué la mise à jour DST 2007, le CRT gère également les dates passées et futures États-Unis. Mises à jour pour le CRT sont répertoriés dans la section Références.

Conversion d’heure locale dans le .NET Framework

Le .NET Framework contient des classes qui stockent et convertissent des horodatages. Ces classes incluent la DateTime classe, la TimeZone classe, la TimeSpan classe et la DateTimeKind classe . Comme indiqué précédemment, ces classes dépendent principalement de l’implémentation de la plateforme sous-jacente. Ces classes présentent le même comportement que les API du système d’exploitation sous-jacentes.

Un comportement intéressant présenté par les classes de date et les classes d’heure .NET Framework concerne les fonctions qui compensent l’horodatage d’une quantité demandée. Par exemple, considérez la AddHours() fonction, la AddMinutes() fonction et la AddSeconds() fonction dans la DateTime classe . Ces fonctions, et les fonctions de même nom, incrémentent simplement l’horodatage par la quantité demandée, sans tenir compte des paramètres d’heure d’été. Ce comportement peut être considéré comme simple arithmétique sur l’horodatage UTC sous-jacent. Toutefois, ce comportement peut entraîner des résultats inattendus lorsque l’ajout entraîne le passage de l’horodatage dans ou hors de l’heure d’été. Ce comportement n’est pas lié aux modifications DST 2007.

Recommandations

Les recommandations suivantes peuvent aider les développeurs à minimiser l’effet de l’heure d’été 2007 et à améliorer la gestion générale des dates et des heures.

  • Vous devez planifier une installation quasi atomique des mises à jour DST 2007. Toutes les mises à jour DST 2007 planifiées doivent être appliquées le plus près possible les unes des autres. Si un ordinateur qui a été mis à jour tente d’utiliser des méthodes telles que des requêtes SQL ou des services Web pour communiquer avec un ordinateur qui n’a pas été mis à jour, des erreurs de traduction peuvent se produire. De même, si un seul ordinateur nécessite au moins deux mises à jour, telles que la mise à jour Windows et la mise à jour CRT, les mises à jour doivent être appliquées en même temps.

  • Les horodatages UTC sont historiquement exacts. C’est généralement la conversion en heure locale qui concerne la plupart des applications. Les applications doivent toujours stocker les horodatages UTC. Les conversions en heure locale à des fins d’affichage nécessitent des informations de fuseau horaire et d’heure d’été. Ces informations peuvent provenir de plusieurs sources :

    • L’application peut utiliser le fuseau horaire actuel et le paramètre DST pour la conversion. Cela peut introduire une inexactitude dans la conversion si le fuseau horaire actuel et le paramètre DST n’étaient pas en vigueur au moment de l’horodatage.

    • L’application peut stocker les informations de fuseau horaire et d’heure d’été précédemment précises en plus de l’horodatage UTC.

    • Lorsque des fuseaux horaires dynamiques sont disponibles, l’application peut utiliser des fuseaux horaires dynamiques pour déterminer les informations de fuseau horaire qui doivent être appliquées à un horodatage UTC particulier. Cette option est disponible uniquement lorsque les informations de fuseau horaire dynamique sont disponibles pour un horodatage spécifique et pour un fuseau horaire spécifique.

    • L’application peut stocker un horodatage local et l’horodatage UTC. Cette méthode évite la nécessité d’une conversion ultérieure.

  • Toute communication entre les ordinateurs qui traitent des horodatages doit utiliser des horodatages UTC. Cela donne implicitement aux deux ordinateurs les mêmes informations de contexte pour UTC.

  • Si une application gère les dates, vous devez faire attention à la façon dont les dates sont gérées dans le cadre du test. Les dates affichées sans informations d’heure sont généralement stockées sous la forme d’un horodatage de 12h00 à la date appropriée. Par conséquent, une erreur off-by-one dans la partie heure de l’horodatage peut entraîner un décalage par un de la date d’effet si l’heure est décalée à 23 :00 le jour précédent.

References