Le hub suit la règle de votre fuseau horaire et change lui-même son horloge. Rien n'est perdu, rien n'est compté deux fois, et les prix restent attachés aux bonnes heures.
Le détail mérite toutefois d'être connu, car le changement touche trois choses à la fois : l'horloge, les enregistrements et les zones tarifaires.
Comment le hub connaît le changement
Il stocke la règle complète du fuseau horaire, et non un décalage fixe : une chaîne comme CET-1CEST,M3.5.0,M10.5.0/3, qui contient les dates de transition. Les préréglages de Settings → Time pour les zones européennes et américaines sont des règles de ce type. Un hub réglé sur un préréglage gère donc le changement tout seul, chaque année, sans rien à faire en mars ou en octobre.
Deux points à surveiller :
- Un décalage fixe ne change jamais. Si le fuseau du hub est saisi comme un simple décalage, il le conserve toute l'année. Seule la chaîne de règle décide : utilisez donc un préréglage ou saisissez une règle valide. (Dans la version 1.1.4 de l'application et antérieures, l'éditeur de configuration brute affichait aussi un indicateur Daylight saving qui n'avait aucun effet. Il a été retiré pour cette raison précise.)
- Les zones de l'hémisphère sud à heure d'été figurent dans la liste des préréglages — Sydney/Melbourne/Canberra/Hobart, Adelaide, Brisbane, Perth, Auckland/Wellington, Santiago, São Paulo/Buenos Aires, Johannesburg — et l'application les détecte depuis votre navigateur comme les autres. Dans l'application v1.1.4 et antérieures, elles n'étaient pas proposées : le hub gérait correctement leurs règles, mais il fallait saisir à la main une chaîne POSIX TZ.
Ce qui arrive aux enregistrements
Les enregistrements horaires sont indexés en UTC, ce qui garde la nuit lisible :
- En automne, l'heure locale répétée correspond à deux heures UTC différentes. Vous obtenez donc deux enregistrements distincts, tous deux conservés, sans que l'un n'écrase l'autre.
- Au printemps, aucune heure ne manque dans les données. L'étiquette locale passe simplement de 01:59 à 03:00.
Les enregistrements journaliers, hebdomadaires et mensuels suivent votre calendrier local. Ainsi, le jour du changement dure réellement 23 heures au printemps et 25 en automne, et la semaine et le mois qui le contiennent sont plus courts ou plus longs d'une heure. C'est normal, pas un défaut : c'est la durée qui s'est réellement écoulée.
Effet visible : un graphique horaire en heure locale affiche une étiquette d'heure deux fois en automne, et en saute une au printemps.
Ce qui arrive au coût
Chaque période de 15 minutes est valorisée selon l'heure locale de son milieu, de sorte que l'énergie reçoit toujours la zone dans laquelle elle est réellement tombée.
Pour une zone de nuit de 23:00 à 07:00, la plage dure donc neuf heures la nuit d'automne et sept la nuit de printemps. L'heure répétée en automne est de l'énergie réelle et se facture au tarif de nuit, comme l'heure précédente.
Seule aspérité : une limite de zone située à l'intérieur de l'heure qui se répète ou disparaît (une plage qui se termine à 02:30, par exemple) sera active deux fois pendant cette demi-heure en automne, et au printemps sa limite tombe à 03:00. Les limites à l'heure pleine en dehors de 02:00–03:00, soit presque tous les tarifs réels, ne sont pas touchées.
Et les compteurs journaliers
Ils se remettent à zéro à minuit heure locale, que le changement ne déplace pas : les transitions européennes et américaines ont lieu entre 01:00 et 03:00. Les totaux du jour couvrent alors 23 ou 25 heures d'énergie réelle, et le repère de jour du hub porte le nouveau décalage à partir du lendemain.
Dans l'application v1.1.4 et antérieures, un décalage était visible ici : ces deux jours-là, les chiffres today de l'application commençaient une heure trop tôt, dès le moment où l'horloge changeait, si bien que « aujourd'hui » incluait discrètement une heure de la nuit précédente. Les enregistrements étaient justes ; ce qu'on lisait sur la Overview était large d'une heure. Corrigé à partir de la v1.1.5, où “today” commence à la vraie minuit du hub aux deux jours de changement.
Vérifié avec les autotests du firmware, qui exécutent le code des enregistrements et des prix sur les vraies dates de transition de Berlin, New York et Sydney. Non observé lors d'un changement d'heure réel.