David Madore's WebLog: Explications et méditations sur le changement d'heure

Heure locale, temps universel et décalage entre eux

Il n'est pas de sujet si simple qu'on ne puisse le rendre incompréhensible par une mauvaise présentation. C'est du moins ce que je me dis en entendant je ne sais combien de discussions et de pseudo « explications » du concept de changement d'heure (passage de l'heure d'hiver à l'heure d'été et vice versa) et la proposition d'y mettre fin. Des phrases absconses comme à deux heures il sera trois heures (à moins que ce ne soit le contraire ?), l'usage de termes comme avancer et retarder ou, pire, gagner une heure et perdre une heure qui semblent inventés pour tout embrouiller : tout pour ne pas parler à Madame Michu du temps universel, selon l'idée préconçue que Madame Michu est forcément trop bête pour entendre parler de temps universel et/ou qu'elle ne veut rien en savoir, et du coup, on ne lui parle que de ce qu'elle voit, et rien ne fait sens. Alors voici une équation dont le niveau mathématique ne fera peur, j'espère, à personne :

heure locale = temps universel + décalage local

Le temps universel continue à avancer tranquillement, mais dans certains endroits comme la France, le décalage local change selon la saison (+1h en hiver, +2h en été) : quand le décalage passe de +1h à +2h fin mars ou revient de +2h à +1h fin octobre, cela donne un « changement d'heure ».

Expliquons plus précisément ce que sont ces trois termes (les notes ne sont là que pour ceux qui aiment les détails supplémentaires) :

• Le temps universel est une mesure du temps qui est la même pour toute la Terre. Il existe en fait toutes sortes de subtilités sur le temps universel, mais je ne veux pas en parler[#] dans cette entrée qui se veut didactique : disons simplement que le temps dont je parle ici s'appelle en fait temps universel coordonné et s'abrège en UTC (ce qui n'est son abréviation ni en anglais ni en français mais c'est comme ça) ; ce temps universel coordonné est maintenu par un réseau d'horloges atomiques dans le monde entier[#2], dont on peut considérer, à moins de faire de la métrologie de très haute précision, qu'elles donnent toutes exactement la même heure, et dont chacune définit, via l'équation ci-dessus, la base du temps légal dans le pays considéré[#3] (par exemple, celle de l'Observatoire de Paris définit le temps légal en France).

  On disait autrefois heure de Greenwich, ce qui est un mauvais terme pour toutes sortes de raisons[#4], mais si quelqu'un parle d'heure de Greenwich, c'est probablement du temps universel qu'il veut parler, et il s'agit plus ou moins du temps solaire moyen mesuré à l'observatoire de Greenwich.

  Ce temps universel ne connaît ni de concept de fuseau horaire ni de concept d'heure d'hiver ou d'heure d'été : il est le même pour toute la Terre et, à des notes en bas de page près, il avance d'une seconde toutes les secondes[#5], c'est aussi simple que ça. (Il ne vous dit pas s'il fait jour ou nuit, parce qu'à tout moment il y a des endroits sur Terre où il fait jour et des endroits sur Terre où il fait nuit.)

  La façon raisonnable de donner une heure pour l'ensemble de la Terre est de la donner en temps universel (par exemple un événement astronomique : le prochain équinoxe — début du printemps boréal — aura lieu le 20 mars 2019 à environ 21:59 temps universel). Chaque lieu convertira alors cette heure en son heure locale en utilisant l'équation ci-dessus (par exemple 22:59 heure de Paris).

• L'heure locale ou heure légale (ou heure locale légale, enfin, vous voyez, quoi) est l'heure qui a valeur légale, qui est censée être celle qu'affichent les horloges du pays ou de l'endroit considéré. En France, l'horloge parlante (ça existe encore, ce truc ?) est une bonne approximation de l'heure légale, ainsi que les les horloges de la SNCF.

  Enfin bref, l'heure locale, c'est l'heure que Madame Michu veut probablement voir affichée sur son ordinateur, téléphone, micro-ondes, ou que sais-je encore.

  L'heure locale est, évidemment, choisie pour coller au moins à peu près avec l'heure solaire moyenne à l'endroit en question (c'est-à-dire grosso modo l'heure indiquée par les cadrans solaires[#6][#7]) : on n'a pas envie que le soleil soit à son plus haut quand les horloges indiquent minuit mais plutôt quand elles indiquent midi. Mais bon à peu près est à dire très très vite : la Chine a la même heure légale d'est en ouest alors qu'il y a environ quatre heures de différence dans l'heure solaire entre les deux extrémités du pays. Et on peut vouloir volontairement décaler l'heure légale par rapport à l'heure solaire parce que les activités humaines ne sont pas forcément centrées par rapport à midi, je vais y revenir.

• Le décalage (local) (i.e., décalage de l'heure locale par rapport à UTC) est, fort logiquement, la quantité qu'il faut ajouter ou retrancher au temps universel pour obtenir l'heure locale. Il est généralement un nombre entier d'heures, même s'il y a des endroits qui font les malins en utilisant des demi-heures (voire des quarts d'heures, I'm looking at you, Nepal). On écrit généralement le décalage sous la forme +hh:mm pour indiquer qu'on ajoute hh heures et mm minutes à UTC pour obtenir l'heure locale, ou −hh:mm pour indiquer qu'on les soustrait (et comme je viens de le dire, mm vaut très souvent 00, auquel cas on peut juste écrire ±hh).

  Il y a essentiellement deux sortes d'endroits (même si je n'exclus pas qu'il y ait des cas vraiment bizarres qui ne rentrent dans aucune des deux cases) :

  • Les endroits qui utilisent un même décalage local tout au long de l'année. Par exemple, l'heure locale en Algérie est définie par un décalage de +01:00, c'est-à-dire que l'heure légale y est une heure de plus que le temps universel (coordonné).
  • Les endroits qui utilisent deux décalages locaux différents, un en hiver (heure d'hiver) et un en été (heure d'été). Par exemple, jusqu'à nouvel ordre, un énorme bout de l'Union européenne (de l'Espagne à la Pologne et la Hongrie, en passant par la France, l'Allemagne, l'Italie et l'Autriche) utilise le même décalage, qui vaut une heure (+01:00) en hiver et deux heures (+02:00) en été (c'est la zone heure d'Europe centrale). Évidemment, à l'échelle de la Terre, personne n'a été capable de se mettre d'accord sur ce que hiver et été veulent dire, même pour un seul hémisphère, donc si un endroit donné change au plus deux fois de décalage par an, sur la Terre entière, c'est beaucoup plus compliqué.

  Même s'il y a toutes sortes d'irrégularités, le décalage local a tendance à être positif et d'autant plus grand qu'on se déplace à l'est de Greenwich (et grosso modo d'une heure par 15° de longitude, cf. la note #7) et négatif quand on se déplace à l'ouest de Greenwich. C'est ce qui permet à l'Australie (UTC+11:00 pour Sydney en été) d'être parmi les premiers à fêter la nouvelle année. Comme il n'aura pas échappé à quiconque que la Terre est plutôt ronde, les endroits avec un décalage très positif (du genre +12:00) ne sont finalement pas très loin des endroits avec un décalage très négatif (du genre −12:00) : la limite entre les deux s'appelle la ligne internationale de changement de date (parce qu'on observera qu'entre un endroit à UTC+12:00 et un endroit à UTC−12:00 l'heure dans la journée est la même et c'est la date qui change)[#8].

  (On remarquera que j'évite soigneusement le terme de fuseau horaire, qui est plus source de confusion qu'autre chose. En général on définit le fuseau par le décalage en hiver, qui est le décalage considéré comme normal, mais l'intérêt de cette définition me semble limité[#8b] : convenons, donc, de ne pas du tout parler de fuseaux.)

À quoi sert ce système d'heure d'hiver et d'heure d'été ? Si on vit proche de l'équateur : à rien du tout, le soleil se couchant à peu près à la même heure toute l'année (la notion d'hiver et d'été étant, d'ailleurs, douteuse). Si on vit proche des pôles, ça ne sert pas à grand-chose non plus (en hiver il fait nuit tout le temps et en été jour tout le temps, alors…). Mais sous des latitudes moyennes où la durée du jour varie entre quelque chose comme 8h et 16h du solstice d'hiver au solstice d'été, il peut y avoir des raisons de ne pas garder le même décalage (au temps universel, donc à l'heure solaire moyenne) tout au long de l'année : l'idée est que, grosso modo, si on a 8h de soleil, on préfère qu'elles tombent entre environ 08:00 et 16:00 heure légale (le midi solaire tombant donc vers 12:00 légal), tandis que si on en a 8h de plus, on va plutôt vouloir rajouter de l'ensoleillement vers la fin de la journée civile que vers le début (puisque les gens, qui font plutôt des choses après leur journée de travail qu'avant, en profiteront plus), peut-être entre 05:00 et 21:00 (le midi solaire tombant alors vers 13:00 légal) ; mais bien sûr, ce qu'on décale, dans l'histoire, ce n'est pas l'ensoleillement, c'est l'heure légale pour la faire coller avec l'ensoleillement : c'est-à-dire qu'on aura envie que le décalage de l'heure légale soit plus important en été qu'en hiver (pour qu'il soit une heure légale plus tardive quand il est midi solaire, de façon à déplacer le midi solaire vers la fin de la journée civile ; ce graphique est plutôt bien fait). On introduit donc un décalage supplémentaire en été : que je sache, ce décalage est toujours presque toujours d'une heure[#8a] (faire plus en une seule fois serait sans doute trop pénible, et faire en plusieurs fois serait sans doute source de confusions encore plus grandes, donc une heure une fois semble être le point évident).

L'introduction de l'heure d'été s'est faite, dans la plupart des pays qui l'utilisent, les années '70 pour des raisons d'économie d'énergie (suite au choc pétrolier). Ce gain d'énergie est controversé. Mes à mes yeux, la principale vertu du changement d'heure est de fournir des journées utilisables plus longues en été plutôt que de gâcher du soleil à un moment où on dort (évidemment, rien ne m'interdit de me lever une heure plus tôt pour profiter de ce soleil, mais le fait est que les activités sociales sont concentrées en fin de journée — essayez de donner rendez-vous à des amis à 6h du matin dans un bar pour prendre un verre avant le travail, si vous voyez ce que je veux dire). Je peine à comprendre pourquoi cet argument évident n'est pas plus mis en avant !

Toujours est-il que le changement d'heure, qui en France correspond au passage du décalage +01:00 (heure d'hiver) à +02:00 (heure d'été) le dernier dimanche de mars, et de +02:00 (heure d'été) à +01:00 (heure d'hiver) le dernier dimanche d'octobre, est un changement d'heure locale venant d'une modification du décalage local à UTC (comme je viens de le dire) et qui n'affecte en rien UTC : le temps universel, lui, n'a rien à faire de cette histoire et continue d'avancer d'une minute par minute comme il le doit.

Personnellement, je retiens le sens du changement d'heure en retenant que la France est à UTC+01:00 en hiver et à UTC+02:00 en été (ce qui est, de toute façon, utile à savoir séparément), mais si j'ai un doute je sais que c'est parce qu'on veut décaler le midi solaire vers la fin de la journée civile en été.

(La suite après les notes…)

[#] Pour ceux qui veulent les subtilités, je vous renvoie à cette page que j'ai écrite il y a longtemps, ainsi qu'aux notes suivantes.

[#2] En fait, les horloges atomiques en question comptent et affichent deux heures différentes : le temps atomique international (TAI, qui compte vraiment une seconde par seconde) et le temps universel coordonné (UTC, qui cherche à rester proche de la rotation de la Terre), lesquels diffèrent toujours d'un nombre entier de secondes. Les deux diffèrent (depuis fin 2016) d'exactement 37s : UTC=TAI−37s. Occasionnellement, ce décalage est modifié d'une seconde par l'ajout (ou, hypothétiquement, la suppression) d'une seconde intercalaire, comme expliqué dans la note #5 ci-dessous. Mais TAI ne nous intéresse pas ici, puisque c'est UTC qui est la base du temps légal.

[#3] Enfin, sauf peut-être une poignée de pays qui cherchent à faire les malins en théorie et sans doute pas en pratique : le Danemark, spécifiquement, censément utilise légalement UT1 au lieu d'UTC, mais c'est un peu une blague (et un truc qui se répète sur Internet) et la loi n'est pas appliquée (comme l'explique la vidéo de Tom Scott).

[#4] La moindre n'étant pas que, pendant l'été, l'heure légale à Greenwich (qui est celle de Londres, évidemment) n'est pas l'heure de Greenwich, ce qui rend ce terme furieusement source de confusion. Une autre étant que, en fait, historiquement, le terme d'heure de Greenwich désignait le temps solaire moyen mesuré à l'observatoire de Greenwich décalé de douze heures puisque les astronomes préfèrent changer de jour à midi où il ne se passe pas grand-chose pour eux. Enfin, parler d'heure de Greenwich ne spécifie pas si on parle de temps universel coordonné ou d'un autre de ses avatars.

[#5] C'est en fait le temps atomique international (TAI) qui compte vraiment une seconde par seconde. Le temps universel coordonné UTC doit parfois être corrigé d'une seconde pour rester dans une marge de ±1s du temps universel astronomique vraiment mesuré (UT1 — enfin, là aussi il y a des subtilités, mais je ne rentre vraiment pas dedans). Lors de l'ajout d'une seconde intercalaire, UTC passe de 23:59:59 à 23:59:60 puis à 00:00:00 le jour suivant, ce qui est une façon de le faire avancer sans vraiment le faire avancer et donc de changer son décalage par rapport à TAI. Comme c'est bien UTC qui définit l'heure légale, il y a des heures légales qui se terminent en :60 secondes, mais vous avez peu de chances d'avoir un réveil ou un ordinateur qui vous les montrera correctement parce que c'est le bordel.

[#6] Correction faite de l'équation du temps.

[#7] Quitte à négliger des subtilités dans la définition du temps universel (et de la longitude), on peut considérer que l'heure solaire moyenne est donnée par : temps universel + longitude/(15°/h) (autrement dit, 15° de longitude apportent une heure de décalage de l'heure solaire moyenne par rapport au temps universel), la longitude étant comptée positivement vers l'est et négativement vers l'ouest. Le décalage « typique » d'un endroit, si on veut que l'heure locale colle à peu près avec l'heure solaire moyenne, sera donc sa longitude divisée par 15°/h.

[#8] Les endroits à UTC+beaucoup sont très à l'est de Greenwich, donc juste à l'ouest de la ligne du changement de date, et les endroits à UTC−beaucoup sont très à l'ouest de Greenwich, donc juste à l'est de la ligne du changement de date. La ligne de changement de date est grosso modo aux antipodes du méridien de Greenwich, même si son emplacement exact dépend des décisions légales des différents pays concernés de se placer à UTC+beaucoup ou UTC−beaucoup (les Samoa ont d'ailleurs décidé, fin 2011, de passer leur fuseau de UTC−11 à UTC+13 pour être plus proches de l'Australie, ce qui leur a fait sauter un jour entier, décalant ainsi localement un peu vers l'est la ligne de changement de date). Mais la providence ayant évidemment placé la nation maîtresse des mers (le glorieux Royaume-Uni de Grande-Bretagne et d'Irlande) aux antipodes de régions où il n'y a rien, le problème était ainsi relégué à un endroit où nul ne s'en souciait.

[#8a] Ajout (2019-03-04) : On me signale l'exemple (unique ?) de Lord Howe Island en Australie, qui ajoute seulement une demi-heure à son déclage pour faire son heure d'été (elle passe de UTC+10:30 en hiver à UTC+11:00 en été).

[#8b] Si un pays décide de passer en heure d'été permanente, faut-il en conclure qu'il a changé de fuseau (puisque c'est maintenant son heure d'hiver comme d'été) ? Ou qu'il est toujours sur le même fuseau mais qu'il n'y est jamais l'hiver ? Quelle question byzantine !

Un (tout petit) peu d'informatique

Parlons un peu informatique, maintenant : quand un système informatique enregistre une date, il y a essentiellement trois possibilités quant aux informations à mémoriser :

1. stocker uniquement le temps universel,
2. stocker uniquement l'heure locale,
3. stocker les deux (ou, ce qui revient au même, l'une des deux — généralement le temps universel — et aussi le décalage).

La solution (A) est globalement satisfaisante : retenir le temps universel d'un événement, c'est justement retenir quand cet événement s'est produit — c'est le situer dans le temps au sens le plus pur. Le temps, pour l'ordinateur, est surtout le temps universel : c'est celui qui permet de mesurer correctement des intervalles et d'ordonner des événements, c'est celui qui est valable dans le monde entier, c'est celui qui est imposé par l'essentiel des formats de stockage. Stocker une date et heure, donc, c'est généralement stocker le temps universel et seulement lui.

L'heure locale est une information pertinente pour communiquer avec des humains, généralement pas pour des calculs informatiques. Un protocole comme NTP (qui sert à synchroniser les horloges d'ordinateurs par réseau) utilise évidemment le temps universel[#9].

La solution (B) est presque toujours épouvantable. Une heure locale sans indication de décalage ne vaut rien, elle ne situe pas un événement dans le temps, elle ne permet pas de calculer des intervalles ni même de trier fiablement. Travailler avec l'heure locale comme information primaire est presque toujours une erreur[#10].

Pour l'anecdote, je suis tellement pointilleux là-dessus que même quand j'écris à la main, en tête d'une feuille de papier, la date et l'heure actuelles (je fais toujours ça en tête de mes brouillons mathématiques pour pouvoir retrouver, plus tard, dans quelle ordre les trier), j'écris la date au format ISO-8601 (=RFC 3339), par exemple 2019-02-22T21:28+01:00, y compris avec son indication de décalage par rapport à UTC.

(Un exemple de cas où je pense quand même que la solution (B) est la bonne serait celui d'une alarme : si je mets une alarme pour le 14 juillet 2022 à 7h du matin heure de Paris, l'ordinateur a intérêt à retenir 7h du matin heure de Paris comme information primaire, même si on ne sait pas encore si 7h du matin heure de Paris sera 05:00 ou 06:00 temps universel puisque les règles pourraient changer !)

Reste la possibilité (C) : stocker les deux (ou, ce qui revient au même, et c'est généralement la forme que cela prendra, stocker le temps universel et le décalage). C'est ce qui se fait, par exemple, pour un mail (selon la RFC 5322) : la date d'expédition note l'heure locale et le décalage en vigueur pour l'expéditeur. J'ai tendance à penser que c'est la meilleure option dès qu'il y a une notion de localité et d'interaction humaine et/ou légale (pour un mail, y a la localité de l'expéditeur, et il est pertinent de savoir non seulement quand le courrier a été expédié au sens chronologie mais aussi quand au sens humain pour l'expéditeur — était-ce pour lui le matin, la journée, le soir, la nuit…). Bref, c'est souvent à discuter au cas par cas[#11].

À part les mails, un exemple de cas où il me semble important de stocker selon cette possibilité (C) à la fois le temps universel et l'heure locale, c'est une photo ou une vidéo : un voyageur veut sans doute que ses photos soient affichées avec l'heure (locale) qu'il était à l'endroit où il les a prises au moment où il les a prise, ce qui implique de mémoriser l'heure locale, en même temps qu'il veut qu'elles soient ordonnées correctement même s'il a franchi une limite de zone horaire (par exemple : pris une photo en Espagne à la frontière portugaise, traversé cette frontière retranchant ainsi une heure à l'heure légale, et pris une nouvelle photo de l'autre côté de la frontière, dont l'heure légale sera ainsi antérieure mais qui sera chronologiquement postérieure). Bref, il y a beaucoup de cas où je pense que la solution (C) est la bonne. (Je regrette qu'elle ne soit pas plus souvent employée ; ou en tout cas, qu'elle soit souvent difficile à appliquer en pratique[#12].)

Maintenant, si les ordinateurs bien faits raisonnent en temps universel, les humains préfèrent généralement qu'on leur affiche une heure locale. Si on n'a que le temps universel, on va donc quand même souvent vouloir le présenter, dans les interactions humaines, sous forme d'une heure locale : si on n'a pas stocké l'heure locale de l'événement considéré à l'endroit où il s'est produit (possibilité (C) ci-dessus) ou si ça n'a tout simplement pas de sens, bref, si on n'a que le temps universel, on veut montrer l'heure locale qu'il était, à l'endroit où on se trouve maintenant, lors de la date considérée (c'est-à-dire pour le temps universel connu).

Pour ça, il faut donc des informations sur le décalage. On pourrait imaginer ne stocker que le décalage actuel, et tout montrer avec ce même décalage : mais ce n'est évidemment pas bon — quand l'ordinateur de Madame Michu passe de l'heure d'hiver à l'heure d'été, elle veut quand même que les heures de modification des fichiers soient montrées à l'heure locale qu'il était quand ces modifications ont été faites, pas soudainement toutes à l'heure d'été ! (Si le système utilisait la possibilité (C) ci-dessus, le problème serait réglé, mais je suppose qu'il n'a stocké, selon la possibilité (A), que le temps universel.) Écartons donc cette idée[#13].

Bref, il faut un tableau de règles permettant de trouver le décalage (de retrouver le décalage pour des dates passées, et de prévoir le décalage pour des dates à venir) entre l'heure légale et le temps universel… pour l'endroit où on se trouve actuellement, mais aussi, idéalement, pour tout endroit sur Terre.

Ce tableau de règles s'appelle la base de données timezone ou base de données d'Olson (du nom de son fondateur, Arthur David Olson). Il s'agit d'une tentative monumentale pour documenter, pour le monde entier, non seulement les fuseaux horaires mais aussi les règles de changement d'heure, à la fois les règles en vigueur actuellement, et celles qui ont eu cours par le passé (sans remonter, évidemment, trop loin dans le passé, parce qu'au bout d'un moment la seule chose qui fait sens est d'utiliser la règle générale décalage = longitude/(15°/h) qui donne le temps solaire moyen).

Et ce qu'on constate, c'est que c'est un chaos indescriptible : les règles n'arrêtent pas de changer. Les législateurs de tous les pays ont l'air de prendre un plaisir pervers à jouer avec les règles de changement d'heure — mais vous ne pouvez pas arrêter d'y toucher sans arrêt, sérieusement ? Il semble y avoir largement un changement par mois, voire plus (janvier 2019 : Metlakatla, Alaska, passe du fuseau pacifique au fuseau alaskan ; décembre 2018 : São Tomé et Príncipe repasse de +01 à +00 ; Kyzylorda, Kazakhstan passe de +06 à +05 ; octobre 2018 : le Maroc décide de rester de façon permanente à +01 ; Volgograd passe de +03 à +04 ; les îles Fiji mettent fin à l'heure d'été une semaine plus tôt ; le Chili change ses règles sur l'heure d'été ; et ainsi de suite). Même en comptant ~200 pays dans le monde, un changement de règles par mois, ça fait un changement de règles tous les ~15 ans par pays (moyenne bidon, évidemment : tous ne sont pas également coupables de cette manie), c'est beaucoup trop selon moi. Manifestement, les gens n'arrivent pas à comprendre que, pour ce genre de choses, il vaut mieux avoir des règles imparfaites que des règles qui changent tout le temps. Mais laissons ça de côté pour le moment.

Bref, il y a de valeureux volontaires (essentiellement Paul Eggert, salué soit-il) qui traquent les changements de changements d'heure(!) dans le monde entier et qui les documentent dans un format informatiquement utilisable (voici par exemple pour l'Europe), et ce fichier est ensuite (compilé puis) distribué à toutes sortes de systèmes informatiques, par exemple les smartphones et les ordinateurs de bureau. (Même si au départ c'était quelque chose pour Unix, je pense que maintenant que c'est standardisé et distribué par l'IANA[#13b], tout le monde utilise la même base de données timezone, il n'y a essentiellement plus de systèmes qui font les malins.) Pour les ordinateurs reliés de façon régulière au réseau, cette base de données timezone va être mise à jour avec les mises à jour ordinaires du système ; pour un système « embarqué » qui ne reçoit des mises à jour que de façon irrégulière, voire jamais, il y a possiblement problème : pas lors du changement d'heure mais lors du changement de règles de changement d'heure (ce qui, je viens de le dire, n'est pas aussi rare qu'on pourrait le souhaiter).

Je me souviens par exemple (mais j'ai déjà dû le raconter plein de fois) que quand je suis entré à l'ENS en 1996, une des premières choses que j'ai pu constater sur le système informatique était que… les ordinateurs retardaient d'une heure (il y avait par exemple le message c'est l'heure du pot — c'est-à-dire l'heure de la cantine — qui s'affichait une heure trop tard). La raison est que jusqu'en 1995, la France passait à l'heure d'hiver le dernier dimanche de septembre, et à partir de 1996 (suite à une harmonisation européenne) le dernier dimanche d'octobre : en octobre 1996, les ordinateurs (sous SunOS) continuaient à appliquer les anciennes règles et étaient donc revenues à l'heure d'hiver alors que l'heure légale était l'heure d'été pour encore un mois. Mettre à jour le système n'était pas si simple à l'époque !, mais il continue à y avoir, et il y aura toujours, des systèmes qui seront difficiles à mettre à jour.

Le paradoxe dans une telle situation, c'est que l'utilisateur, voyant un ordinateur qui affiche une heure incorrecte, va se demander mais pourquoi on ne peut pas juste le remettre à l'heure ? — et ce n'est pas une question dénuée de fondement. C'est ce que j'avais moi-même demandé en 1996. On ne peut pas juste le remettre à l'heure parce que l'ordinateur est à l'heure, pour ce qui est du temps universel, il le reçoit par réseau, et c'est ça qui est le plus important. (Forcer un changement d'heure casserait le temps universel et toutes sortes de choses subtiles qui vont avec.) Ce qui est incorrect n'est pas l'heure, c'est le décalage local ; et il n'est pas prévu de corriger facilement le décalage local : généralement, on demande juste à l'utilisateur de choisir l'emplacement (parmi un ensemble de villes) dont on veut appliquer les règles. Ce n'est pas tout à fait vrai, évidemment, il y a moyen de forcer le décalage, soit en appliquant les règles d'un autre endroit, soit en forçant une valeur numérique, ou même en imposant des règles explicites[#14]… mais essayez de convaincre votre smartphone Android ou iOS de passer à l'heure d'été à un moment différent, ce ne sera sans doute pas facile.

Certains informaticiens considèrent (à raison selon moi) que le temps qui importe vraiment c'est le temps universel[#14b] et en concluent (à tort selon moi) que l'heure locale est uniquement un problème d'interface utilisateur, sans grande importance. Ce point de vue néglige le fait que Madame Michu est parfaitement en droit d'attendre que son ordinateur ou smartphone affiche correctement l'heure locale et ne se satisfera pas de la réponse oh, le temps universel est correct, c'est juste l'affichage qui buggue : pire, prise entre des gens qui considèrent qu'elle n'a pas à savoir ce qu'est le temps universel et un système qui lui affiche une heure locale fausse, elle va sans doute chercher par tous les moyens à corriger l'heure, ce qui, au mieux, ne marchera pas, et au pire, le décalage étant faux, donnera un temps universel faux, ce qui peut causer toutes sortes de problèmes insidieux. Rendons le pouvoir à Madame Michu !

Ce qu'il faudrait, donc, c'est (1) permettre très facilement de mettre à jour la base de données timezone (même sur des systèmes embarqués, et ce, sans mettre à jour tout le système)[#15], (2) fournir une interface utilisateur simple (utilisable même par Madame Michu) pour (a) afficher le décalage local actuel (pas juste sous forme de nom de ville mais d'heures+minutes par rapport à UTC), (b) le corriger manuellement s'il est faux, et peut-être même (c) saisir manuellement des règles spécifiques, et aussi (3) fournir une abondance de moyens de bloquer les problèmes qui peuvent survenir de la diffusion d'une heure locale fausse ou d'un décalage faux (par exemple je crois que le réseau GSM permet la dissémination de l'heure et du décalage[#16] locaux, mais (i) je crois que certains opérateurs renseignent mal l'un ou l'autre et (ii) il n'est pas du tout clair comment le téléphone doit réagir en cas de changement du décalage local et comment interpréter s'il s'agit d'un changement de fuseau ou d'un changement d'heure — l'utilisateur doit donc avoir toute latitude pour corriger une éventuelle interprétation erronée).

(La suite après les notes…)

[#9] Enfin, évidemment… Il y aurait à dire de l'argument selon lequel il serait peut-être plus opportun d'utiliser le temps atomique international (TAI). Encore une fois, je renvoie à ce manifeste pour ma proposition et ma position (en bref : utiliser UTC, mais le gérer correctement et fiablement) sur comment résoudre ce merdier.

[#10] Hélas, le système de fichiers FAT et ses descendants directs utilisent, justement, l'heure locale pour noter la date de modification des fichiers. Hélas aussi, certains systèmes d'exploitations insistent, ou préfèrent, stocker l'heure locale plutôt que le temps universel dans l'horloge persistante de l'ordinateur. Ces erreurs historiques continueront de causer des problèmes pour encore un moment. (Sous Unix, c'est particulièrement emmerdant, parce que la notion d'heure locale n'est même pas vraiment définie, c'est juste un truc d'affichage : voir cependant ce post.)

[#11] Exemple de cas précis : je vais à San Francisco, j'informe évidemment mon ordinateur portable de l'heure qu'il est (c'est-à-dire que je lui donne le décalage, ou bien il le déduit de l'information qu'il est à San Francisco, et le temps universel est obtenu par réseau) ; je tape une note dans cet en fin d'après-midi, je rentre à Paris : une fois mon ordinateur remis à l'heure de Paris (c'est-à-dire informé du nouveau décalage), quelle heure doit-il m'afficher pour le fichier ? Mes trois possibilités seraient grosso modo : (A) afficher l'heure de Paris qu'il était quand le fichier a été créé (le système de fichiers ayant mémorisé le temps universel, sans retenir le décalage, et il est maintenant converti en heure de Paris), (B) afficher l'heure de San Francisco sans précision particulière (le système de fichiers ayant mémorisé l'heure locale, sans retenir le décalage), ou (C) afficher l'heure de San Francisco avec une précision particulière attirant l'attention que c'est une heure « hors fuseau », équivalente à telle heure de Paris (le système ayant mémorisé à la fois le temps universel et le décalage). [Correction : j'avais écrit cette note avec San Francisco une fois sur deux et New York une fois sur deux à cause d'un changement d'avis en cours d'écriture — j'ai rectifié pour mettre San Francisco partout.]

[#12] Un système de base de données comme PostgreSQL ne permet pas simplement de stocker une heure locale avec son décalage. C'est pire que ça : le type timestamp with time zone de SQL mémorise un temps (en étant capable de le convertir depuis ou vers n'importe quelle zone horaire) sans mémoriser d'information de décalage, ce qui est en gros la première possibilité que je listais et atrocement confusant compte tenu du nom du type. Le type timestamp without time zone de SQL mémorise la même quantité d'information et peut servir pour une heure locale ou un temps universel (la seule différence entre les deux est l'intention du programmeur, pas la donnée stockée). Voir aussi cette réponse StackOverflow. Mais rien n'est prévu pour stocker commodément une heure et un décalage comme dans ma possibilité (C).

[#13] Une autre possibilité imaginable (à part tout montrer selon le décalage actuel et tout montrer selon les règles applicables au lieu actuel) serait que l'ordinateur retînt au fil du temps le décalage définissant son heure locale : ce ne serait pas forcément absurde, mais je ne sais pas si c'est optimal : ça voudrait dire, par exemple, que si Madame Michu a fait un voyage à San Francisco en juillet 2018, son ordinateur lui montrerait ensuite les heures pour juillet 2018 à UTC−07:00, ce qui fait peut-être sens pour les fichiers qu'elle aurait créés sur place, cf. la note #11, mais pas forcément pour les autres ! Et de toute façon, ça ne résout pas le problème des dates à venir pour lesquelles on ne peut que prévoir le décalage en utilisant un système de règles.

[#13b] Y compris le format binaire depuis très récemment.

[#14] Sous Unix, cela se fait en réglant la variable d'environnement TZ : par exemple TZ=Asia/Tokyo date me donne l'heure qu'il est actuellement à Tōkyō, TZ=Etc/GMT-02 règle l'heure à UTC+02:00 (oui, c'est horrible, le signe est inversé) ; et si on écrit quelque chose comme TZ="ParisHiver-1ParisEte,M3.5.0/2,M10.5.0/3" il me semble que ça définit, dans cette syntaxe abominable, les règles utilisées actuellement pour la France.

[#14b] Sous Unix, la notion d'heure locale n'est même pas vraiment définie (cf. aussi les notes #10 et #14 ci-dessus), ou dans la mesure où elle l'est, elle est spécifique à un processus (ce qui est logique du point de vue interface utilisateur : un ordinateur peut s'utiliser à distance, et ce qui compte comme heure locale est celle de l'endroit d'où on l'utilise pas celle de l'endroit où s'avère être sis l'ordinateur, même si ce dernier servira de valeur par défaut).

[#15] Il semble qu'Android ait adopté quelque chose de ce genre dans ses versions récentes. Mais comme d'habitude avec Android, c'est extraordinairement compliqué, je ne peux pas juste aller sur un site Web récupérer la dernière version et la mettre en place simplement, non, non, ce serait bien trop simple.

[#16] Exprimé, si j'en crois certaines sources, en quarts d'heure par rapport à UTC.

Vers la fin du changement d'heure en Europe ?

L'Union européenne impose actuellement (directive 2000/84/CE du Parlement européen et du Conseil du 19 janvier 2001 concernant les dispositions relatives à l'heure d'été) que l'heure d'été dure, pour l'ensemble de l'Union européenne, du dernier dimanche de mars à 01:00 temps universel, jusqu'au dernier dimanche d'octobre à 01:00 temps universel[#17]. Je ne comprends pas bien dans quelle mesure cette directive (ou d'autres parties du droit européen) impose aux états membres de pratiquer un changement d'heure ou impose seulement que si il y a changement d'heure alors il a lieu aux dates que je viens de dire. (J'avais toujours cru comprendre que c'était cette dernière interprétation qui était la bonne, et ma lecture comme non-juriste de la directive elle-même semble aller plutôt dans ce sens, mais j'ai entendu des gens prétendre le contraire et le fait qu'on rapporte que la Commission entend mettre fin au changement d'heure semble suggérer que la directive l'impose — notons j'ai peut-être changé plusieurs fois entre des univers parallèles.)

Le changement d'heure agace apparemment beaucoup de gens qui se plaignent soit du désagrément de devoir changer l'heure de toutes sortes de gadgets électroniques (pourtant de moins en moins nombreux vu le nombre de choses qui connaissent les règles comme je l'ai expliqué plus haut, ou qui reçoivent l'heure locale via GSM, radio ou équivalent), et/ou de celui d'avoir une heure de sommeil (ou de week-end) de moins fin mars. La Commission européenne a lancé en 2018 une consultation pour savoir ce que les Européens pensaient du changement d'heure et la réponse a été que 84% des personnes consultées y sont opposés et voudraient y mettre terme (les résultats varient selon les pays : la Grèce, Chypre et Malte sont les plus favorables au changement d'heure, la Finlande et la Pologne les plus défavorables — il y a sans doute un effet de la latitude mais il n'est pas vraiment celui que j'attendais) : la Commission Juncker a donc initialement pensé mettre fin au changement d'heure dès 2019, mais les États membres ont fait savoir que les difficultés techniques n'étaient pas minces et le projet est sans doute reporté à 2021 (voire plus loin si des difficultés importantes surgissent). Si le changement d'heure est aboli, les États membres auraient le choix, chacun pour sa part, entre rester de façon permanente sur l'heure d'hiver (qui est plus ou moins considérée comme son heure normale : c'est l'heure d'été qui est une heure avancée, pas l'heure d'hiver qui est une heure reculée) ou rester de façon permanente sur l'heure d'été ; même s'il y a lieu de s'inquiéter, comme je vais le dire plus bas, que toutes sortes de problèmes ne surviennent si, par exemple, la France et l'Allemagne ne font pas le même choix.

L'Assemblée nationale française mène actuellement sa propre consultation à ce sujet (le questionnaire est assez mal fait, les deux dernières questions sont redondantes, et il y a aussi une question extrêmement obscure où on demande l'importance qu'aurait le fait de maintenir ou de ne pas maintenir le changement d'heure — passons).

Je voudrais donner mon propre avis sur le sujet.

Je suis clairement dans la minorité parce que je suis tout à fait favorable au changement d'heure ; mais dans la mesure où il doit être supprimé, je préfère largement une heure d'été permanente (c'est-à-dire mettre la France à UTC+2 plutôt que le UTC+1 de l'heure d'hiver actuelle). Expliquons un peu mes raisons :

• Si je dois choisir entre UTC+2 (heure d'été permanente) et UTC+1 (heure d'hiver permanente), je préfère largement UTC+2. La raison est celle que j'ai déjà expliquée plus haut : fournir des journées utilisables plus longues en été plutôt que de gâcher du soleil à un moment où on dort ; en effet, les activités humaines ne sont pas centrées sur le midi solaire (qui, à Paris, à des fluctuations près dues à l'équation du temps, a lieu à peu près à 11:50 temps universel, c'est-à-dire 12:50 à l'heure d'hiver et 13:50 à l'heure d'été). Si on a une longue période de soleil, il vaut mieux la répartir autant que possible sur les moments où on fait quelque chose de la journée. Évidemment, le fait que je sois du genre à me lever tard et me coucher tard (par rapport à l'heure légale) joue dans ma préférence, mais comme je le disais plus haut, ce n'est pas que moi, beaucoup plus de gens sortent en soirée après le travail qu'en matinée avant le travail ! À titre d'exemple, le 1er mai[#19] prochain, le soleil se lèvera à Paris à 04:31 temps universel et se couchera à 19:05 : en UTC+1 cela correspond à 05:31→20:05, tandis qu'en UTC+2 (règle actuelle) cela correspond à 06:31→21:05 : le second me semble nettement préférable, je pense qu'il y a plus de gens qui veulent profiter du soleil autour de 20h30 qu'autour de 6h du matin.
• Je donne cet argument pour la France, mais il est d'autant plus fort qu'on est à l'est du fuseau : il est peu vraisemblable que la Pologne ou même l'Allemagne aient envie de passer en UTC+1 permanent (ce qui donnerait du soleil de 04:35 à 19:32 le 1er mai à Berlin, ce serait vraiment idiot alors que 05:35→20:32 en UTC+2 comme actuellement, est tout à fait raisonnable). Comme il y a toutes sortes de raisons de vouloir que le bloc reste uni (je vais y revenir), le UTC+2 semble nettement préférable. Même l'Espagne, qui est très à l'ouest dans le fuseau, a probablement culturellement l'habitude de profiter de soirées étendues et pourrait donc aussi préférer UTC+2.
• L'hiver, l'argument est beaucoup moins fort (les journées sont de toute façon bien courtes, ça m'est un peu égal comment le soleil y est réparti, il tombera de toute façon à un moment utile). Je comprends un peu qu'il soit désagréable que le soleil se lève à 09:41 le 22 décembre à Paris, si on passe à UTC+2 permanent — mais bon, à UTC+1 comme actuellement il est déplaisant qu'il se couche à 16:56, de toute façon c'est pénible d'avoir si peu de soleil. Disons que pour mon confort vraiment égoïste, UTC+2 est peut-être préférable, mais j'ai tendance à penser qu'à un niveau plus général, UTC+1 est sans doute plus adapté en hiver.
• Je suis très sceptique quant à l'argument qui veut que le changement d'heure perturbe le rythme circadien : cet argument est crédible venant de gens qui se lèvent tous les jours à la même heure (ce qui est, effectivement, sans doute une bonne idée pour la santé), mais j'ai plein de raisons de croire que l'immense majorité de mes compatriotes ne se lèvent pas du tout à la même heure le week-end et en semaine (une raison étant, par exemple, la manière dont il est culturellement admis de faire du bruit le vendredi ou samedi soir sous prétexte que le lendemain les gens peuvent se lever plus tard). Si on est capable de changer d'heure de lever et de coucher deux fois par semaine (et probablement par un écart plus important qu'une heure), je pense qu'on doit y arriver deux fois par an !…
• …Mais tant qu'à donner des ressentis sur le bien-être, voici le mien : je vis chaque année le passage à l'heure d'été comme un moment de grand bonheur — comme une victoire symbolique de la lumière sur l'obscurité, c'est un véritable plaisir de voir arriver le dernier dimanche de mars, je ne me soucie franchement pas d'avoir une heure de sommeil en moins. Je dis ça aussi au sujet de l'argument les gens ne se rendent pas forcément compte de l'impact négatif que peut avoir sur eux le changement d'heure : symétriquement, il est possible qu'ils ne se rendent pas compte de l'impact positif qu'il pourrait avoir.
• Je suis aussi profondément sceptique quant à l'argument qu'on entend souvent concernant la traite des vaches (elles donneraient moins de lait ou seraient toutes perturbées lors du changement d'heure). Que je sache, les vaches ne portent pas de montre : rien n'interdit aux agriculteurs de les traire selon l'heure solaire vraie, ou au moins de « lisser » le décalage horaire sur plusieurs jours ou plusieurs semaines.
• Enfin, si je comprends l'argument selon lequel il est agaçant de devoir remettre à l'heure toutes sortes de pendules et de gadgets électroniques, de plus en plus d'entre eux rendent cette opération très simple ou purement automatique selon les mécanismes que j'ai évoqués plus haut…
• …A contrario, si on change les règles, le temps que les nouvelles règles soient répercutées à tous ces gadgets (c'est-à-dire probablement jamais), ils afficheront une heure fausse la moitié de l'année, et il sera désagréablement difficile de les corriger (comme expliquer plus haut). On accepterait donc d'avoir plein de gadgets qui indiquent une heure fausse pour éviter d'avoir plein de gadgets dont on doit changer l'heure deux fois par an, cela ressemble un peu à un marché de dupes.
• Il vaut mieux avoir des règles imparfaites que des règles qui changent tout le temps (autrement dit : stare decisis). Un changement par siècle me semble un bon maximum : on a changé les règles européennes à ce sujet en 1996, je propose d'attendre 2096 pour le prochain changement (on peut certes lancer la concertation dès maintenant, mais imposer au moins 50 ans entre la publication de nouvelles règles et leur entrée en vigueur me semble un bon principe).[#20]

J'avais répondu au sondage de la Commission et écrit dans les commentaires quelque chose comme si vous envisagez de changer les règles, il est essentiel que vous consultiez beaucoup d'informaticiens, et notamment les spécialistes de la base de données d'Olson (à commencer par son mainteneur Paul Eggert) pour savoir combien de temps il faut pour prévoir les changements et les répercuter sur la quasi-totalité des systèmes où la base de données est diffusée. Je suppose que ce genre de commentaires passe à la trappe, mais sait-on jamais.

Je ne sais pas comment tout cela va finir, mais j'espère au moins une chose, c'est que le bloc européen central restera uni dans son heure et dans ses règles : il y a certainement toutes sortes de systèmes ou de procédures transfrontalières qui supposent insidieusement que la France et l'Allemagne sont à la même heure, par exemple, que je prédis les pires tracas du monde si cet invariant cessait d'être vérifié — tracas qu'on ne découvrirait, évidemment, que trop tard. (Il y aurait, en outre, un coût symbolique important qui se paierait politiquement.) Et ceci vaut probablement pour la plupart des paires de pays limitrophes qui ont la même heure depuis fort longtemps. Un simple exemple : je suis sûr il y a énormément de gadgets en France (j'en ai plusieurs), et sans doute plein de choses qui ne sont pas des gadgets, qui se mettent à l'heure automatiquement en se synchronisant sur le signal DCF77 (l'émetteur de temps à la fréquence de 77.5kHz situé à Mainflingen, près de Francfort-sur-le-Main) : ce signal donne l'heure légale allemande et s'il est utilisé en France c'est bien sous l'hypothèse que cette heure est aussi celle de la France.[#21]

Toujours est-il que si (de mon point de vue : malheureusement) l'Union européenne décidait effectivement de mettre fin au changement d'heure, je préconise la façon suivante de « réparer » beaucoup de gadgets qui, inévitablement, se mettront à afficher la mauvaise heure :

• Si le pays adopte UTC+1 de façon permanente : régler l'heure du gadget sur celle d'Alger, par exemple, qui est déjà de façon permanente à UTC+1 (et depuis assez longtemps, contrairement à, par exemple, Tunis, qui s'amuse occasionnellement à pratiquer l'heure d'été) et semble utiliser la désignation d'heure normale d'Europe centrale.
• Si le pays adopte UTC+2 de façon permanente : régler l'heure du gadget sur celle de Johannesbourg, par exemple (Johannesbourg est à UTC+2 depuis longtemps mais l'inconvénient d'utiliser la désignation d'heure standard Sud-Africaine) ou peut-être le Caire (aussi à UTC+2 mais de façon permanente pas depuis si longtemps).

On évitera les pays comme le Maroc qui ont l'air de jouer avec leurs règles sur le décalage avec une fréquence complètement indécente (et selon des considérations comme la date du Ramadan). Évidemment, ce serait mieux si le gadget proposait l'option explicite de régler le décalage à UTC+1 (resp. UTC+2) permanent, mais c'est rarement le cas.

[#17] Ce qui veut dire que, en Europe, l'heure d'été commence au même moment sur tout le continent (et les pays conservent donc un décalage constant les uns par rapport aux autres[#18]), contrairement à l'Amérique du Nord où l'heure d'été commence à la même heure (locale) sur tous les endroits qui la pratiquent.

[#18] Je me rappelle avoir fait un voyage scolaire à Stratford-upon-Avon fin 1991 (du 25 au 28 octobre 1991 si mes inférences sont bonnes), à une époque où la France passait à l'heure d'hiver le dernier dimanche de septembre et le Royaume-Uni le quatrième dimanche d'octobre, et nous étions pile sur l'un des deux — plutôt le quatrième dimanche d'octobre, cela colle mieux avec mes souvenirs : quand nous sommes partis la France et le Royaume-Uni devaient être à la même heure, mais le Royaume-Uni a changé d'heure pendant que nous étions sur place, ce qui a été source de beaucoup de confusion. (À l'époque il n'était pas si facile d'obtenir ce genre d'information !)

[#19] Le questionnaire de l'Assemblée nationale utilise le solstice d'été comme exemple, mais c'est un peu biaisé : au solstice, on a de toute façon tellement d'heures de soleil qu'on ne sait plus quoi en faire ; c'est plutôt vers mai qu'il est très agréable de pouvoir profiter des heures de soleil supplémentaires en fin de journée !

[#20] OK, je ne suis pas totalement sérieux, là. Mais demandons-nous par exemple : le calendrier grégorien, il n'est pas complètement satisfaisant — quel niveau de désagrément, quel niveau de consensus, quel niveau d'annonce à l'avance, faudrait-il demander pour imaginer le changer ? Je crois que ce serait audacieux de changer même pour l'année 2100. En tout état de cause, je trouve que la Commission a complètement déliré en imaginant pouvoir annoncer en 2018 un changement pour 2019 !

[#21] À la limite, si le bloc ne doit pas rester uni, je ne comprends pas plus l'intérêt d'imposer qu'il n'y ait pas de changement d'heure que d'imposer qu'il ait lieu : si on doit de toute façon être capable de gérer le fait que la France et l'Allemagne ne soient pas à la même heure, je ne suis pas sûr que ça apporte grand-chose de pouvoir supposer que le décalage est constant au cours de l'année ; autrement dit, comme je disais sur mon interprétation initiale de la directive 2000/84/CE, imposer simplement aux États membres que si il y a changement d'heure alors il a lieu le dernier dimanche de mars à 01:00 temps universel et le dernier dimanche d'octobre à 01:00 temps universel.