Réglez vos montres : des calculs de date et d'heure passées plus précis sur le Web

Réglez vos montres : des calculs de date et d'heure passées plus précis sur le Web

Pour toucher un public mondial, les développeurs Web souhaitent créer des applications internationales. Avec Internet Explorer 10, le concept d'heure d'été pour les dates passées, déjà disponible dans le système d'exploitation sous-jacent, est désormais entre les mains du développeur Web. Les applications et les sites peuvent ainsi interagir avec les dates et les heures passées de façon plus précise sur plusieurs fuseaux horaires.

Au début de l'année, nous avons exploré les récentes API ECMAScript Internationalization, qui permettront par exemple des représentations en devises et des comparaisons de chaînes prenant en compte les paramètres régionaux au sein de la plateforme des standards Web, des scénarios qui nécessitaient auparavant une interopérabilité native ou un plug-in. Dans le même esprit, afin d'internationaliser la plateforme Web, nous avons publié une démonstration qui montre comment les navigateurs interagissent avec les informations de date et d'heure passées.

Problématiques liées aux calculs de date et d'heure passées

Lors des interactions avec des dates passées (interprétation des cours passés d'une action, dates d'anniversaire, événements historiques), les développeurs Web doivent souvent réaliser une validation sur le serveur. Les développeurs doivent s'appuyer sur le serveur, car les ajustements d'heure d'été appliqués aux dates par les moteurs JavaScript actuels ne sont pas aussi précis que les plateformes couramment exécutées sur le serveur (.NET, PHP/Perl, Java, etc.). En plus des inexactitudes liées aux dates JavaScript passées, bien souvent l'interopérabilité entre les plateformes des navigateurs n'est pas au rendez-vous. Ainsi, les développeurs ne peuvent pas s'appuyer de façon fiable sur les dates ajustées en heure d'été générées en JavaScript.

IE10 est le tout premier navigateur offrant des dates ajustées en heure d'été plus précises, conformes aux modifications apportées à la section 15.9.1.8 de l'ébauche de la spécification ECMAScript 6. Nous avons étendu les fonctionnalités de la plateforme Web en nous appuyant sur les scénarios dans lesquels les développeurs Web doivent interagir avec le serveur pour accomplir leur travail. Nous avons étudié de quelle manière les moteurs JavaScript interprètent les dates passées et les ajustent pour l'heure d'été. Nous avons remarqué un défaut dans la spécification des standards ECMAScript. Celui-ci empêche l'amélioration de la précision des implémentations JavaScript existantes lors de l'ajustement à l'heure d'été. Nous avons collaboré avec le comité chargé de l'établissement des standards ECMAScript et proposé une modification de la spécification, afin de rendre la prochaine version de la spécification ECMAScript plus claire.

Exploration de la démonstration Test Drive

Pour illustrer ce problème et constater comment votre navigateur habituel traite les dates passées, vous pouvez vous amuser avec la démonstration Historic Dates Test Drive, en cliquant sur l'icône d'un événement de l'histoire de l'aéronautique (en bas de la démonstration). Lorsque vous cliquez, le navigateur lit la date passée de l'événement et affiche la date et l'heure en appliquant la règle d'heure d'été utilisée par défaut par le navigateur pour la date de l'événement. La démonstration vérifie ensuite si la date passée et l'heure d'été sont correctes.

Dans le cas ci-dessus, lorsque vous affichez la date passée du lancement de la navette IMAGE, IE10 exécuté sur un ordinateur Windows 8 dans le fuseau horaire PST (heure du Pacifique) peut maintenant déterminer avec précision la date correcte et l'heure d'été de l'événement passé.

Remarque : l'heure d'été ne s'applique pas à tous les fuseaux horaires, et dans certains fuseaux horaires, les règles d'heure d'été n'ont jamais évolué. Si votre système se trouve dans l'une de ces zones, nous vous recommandons de changer le fuseau horaire de votre système au profit d'un fuseau dans lequel des règles d'heure d'été existent et où ces règles ont évolué au fil du temps (fuseau PST, par exemple), puis d'exécuter de nouveau la démonstration. IE10 détecte immédiatement le changement de fuseau horaire du système, mais si vous utilisez un autre navigateur, vous devrez peut-être redémarrer le navigateur pour que le nouveau fuseau horaire soit pris en compte.

Traitement amélioré des dates et heures passées dans IE10

Examinons de plus près de quelle manière la spécification ECMAScript actuelle influe sur la précision de l'ajustement des dates pour l'heure d'été en JavaScript :

la section 15.9.1.8 de la spécification ECMAScript 5.1 indique que les implémentations JavaScript telles que celles du moteur Chakra d'Internet Explorer doivent suivre les recommandations suivantes dans le cadre du traitement des dates passées :

L'implémentation d'ECMAScript ne doit pas essayer de déterminer si l'heure exacte était soumise à l'heure d'été, mais simplement déterminer si l'heure d'été aurait été appliquée si l'algorithme d'heure d'été actuel avait été utilisé à la date en question. Ce principe permet d'éviter certaines complications. Il n'est notamment pas nécessaire de prendre en compte les années pendant lesquelles le pays ou la région en question a utilisé l'heure d'été toute l'année.

Si l'environnement hôte offre une fonctionnalité permettant de déterminer l'heure d'été, l'implémentation d'ECMAScript peut mapper l'année en question à une année équivalente (même « bissextilité » et jour de semaine identique comme premier jour de l'année) pour laquelle l'environnement hôte fournit des informations d'heure d'été. La seule restriction est que toutes les années équivalentes doivent générer le même résultat .

Pour simplifier, cela signifie que pour traiter une date passée, une implémentation JavaScript doit soit appliquer l'algorithme actuel d'heure d'été à une date passée, soit déterminer le jour correspondant au 1er janvier de l'année, calculer s'il s'agissait d'une année bissextile, trouver les règles d'heure d'été actuelles d'une année présentant les mêmes attributs (jour de départ et bisssextilité), puis appliquer cette heure d'été spécifique à la date passée. Par exemple, l'année 1972 était une année bissextile qui a commencé un samedi. L'année bissextile suivante qui a commencé un samedi était l'année 2000. Selon la spécification du langage, les implémentations JavaScript peuvent utiliser soit les règles actuelles d'heure d'été, soit les règles en vigueur en l'an 2000 pour manipuler les dates de l'année 1972.

Deux problèmes importants se posent lorsque l'une ou l'autre des règles ci-dessus est utilisée pour appliquer des règles d'heure d'été à des dates passées. Tout d'abord, les règles d'heure d'été d'un fuseau horaire spécifique ne sont pas immuables et évoluent au fil du temps. Ainsi, le risque est d'appliquer des règles incorrectes à une date passée. Par ailleurs, pour les fuseaux où les règles d'heure d'été ont évolué au fil du temps, les applications Web ne peuvent plus maintenir la parité pour les dates passées calculées par la plateforme du système d'exploitation sur lesquelles elles sont exécutées, ce qui oblige souvent les développeurs à « bidouiller » pour contourner ces problèmes d'interopérabilité entre les applications Web et la plateforme sur laquelle elles sont exécutées.

Le texte de la spécification ECMAScript 5.1 (section 15.9.1.8) ci-dessus autorise les implémentations incorrectes en matière d'ajustement pour l'heure d'été, mais il les oblige en revanche à essayer d'être exactes, dans une certaine mesure. Ce principe est quelque peu contre-intuitif et dans la pratique, aucun consensus entre les navigateurs n'a été établi. Au lieu de contraindre le comportement de décalage des fuseaux horaires comme dans la section 15.9.1.8, la spécification devrait conserver une implémentation DaylightSavingsTA dépendante.

Nos tests ont montré qu'aucune des implémentations de navigateur existantes (dernières versions) ne respecte entièrement le comportement spécifié dans le standard d'une plateforme à l'autre. En outre, en matière de dates, elles ne sont pas très précises lors de l'ajustement pour l'heure d'été. Voici quelques exemples montrant les différences existantes pour le fuseau PST (heure du Pacifique) :

Date	Windows					Debian	Mac
	IE9	Chrome	Firefox	Opera	Safari	Node	Node	Chrome	Firefox	Safari
4/1/2000	420	420	420	420	420	420	480	480	480	420

Vous remarquerez que pour cette date, Chrome, Firefox et Node ne sont pas cohérents d'un système d'exploitation à l'autre. Presque tous les résultats sont erronés, car l'ajustement réel pour l'heure d'été était 480.

Date	Windows					Debian	Mac
	IE9	Chrome	Firefox	Opera	Safari	Node	Node	Chrome	Firefox	Safari
3/10/2011	480	480	480	480	480	480	480	480	480	480
3/10/2109	480	480	480	480	420	480	480	480	420	420

Pour cette date, quelques environnements enfreignent de nouveau les règles de la spécification ES5.1 (ces deux années commencent un mardi et ne sont pas des années bissextiles), mais des incohérences apparaissent également sur un même système d'exploitation (aussi bien sur Windows que sur Mac).

Perspectives

Depuis Internet Explorer 10, le moteur Chakra utilise désormais les informations d'heure d'été disponibles auprès de la plateforme Windows exécutée par le navigateur pour convertir les heures locales en heures UTC. 

Suite au signalement du problème de spécification et à notre collaboration avec le comité chargé de l'établissement des standards ECMAScript en vue de rendre la prochaine version de la spécification ECMAScript plus claire et de permettre à la plateforme Web d'être interopérable et plus précise, la dernière version de travail de la spécification ECMAScript 6 détaille désormais la manière dont les règles d'heure d'été améliorées et exactes doivent être appliquées aux dates pour générer des informations plus précises. IE10 est le tout premier navigateur à respecter la nouvelle version de la spécification et nous espérons que les autres navigateurs amélioreront également leur prise en charge au cours des prochaines versions afin de résoudre les problèmes évoqués. Ainsi, les développeurs Web pourront créer des applications enrichies et internationales.

À l'heure où la plateforme Web prend de l'importance, la logique des applications enrichies est de plus en plus souvent écrite entièrement en JavaScript, y compris celle utilisée par les applications de calendrier, les tableurs, les logiciels de gestion de projets, etc. Pour permettre aux développeurs d'assurer une compatibilité optimale, cette modification est activée uniquement dans le mode standard d'IE10. Si vous calculez des dates passées dans vos applications Web et que vous avez mis en place une logique personnalisée pour contourner les problèmes d'imprécision des navigateurs, il peut être utile de vérifier que la logique personnalisée continue à fonctionner correctement lorsque vous mettez à niveau vos applications Web pour qu'elles fonctionnent avec IE10.

-- Suresh Jayabalan, chef de projet, équipe JavaScript