From 44500f59967ee32cef7c89e5fce265807e78d7fb Mon Sep 17 00:00:00 2001 From: Patrick Schurig Date: Sat, 5 Sep 2026 08:54:42 +0200 Subject: [PATCH] =?UTF-8?q?ops(banc):=20.75=20passe=20en=20Europe/Paris,?= =?UTF-8?q?=20et=20la=20couture=20est=20dat=C3=A9e?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `Europe/London` sur un banc français était une erreur de configuration. La correction a été différée tant que le décalage n'était pas visible : déplacer les frontières d'une heure sans rien qui le dise aurait rendu l'historique illisible de part et d'autre, sans qu'aucun lecteur ne puisse savoir où passait la couture. `periodStartedAt`, posé hier, a levé cette réserve. COUTURE : 2026-09-05T06:53:30Z. Avant, journée de reporting de 23:00 à 23:00 UTC ; après, de 22:00 à 22:00. Toute comparaison jour à jour qui franchit cet instant compare deux découpages différents. Méthode : `Configuration.SetTimeZone` en JSON-RPC. `System.SetTimeZone` N'EXISTE PAS en 1.15.2 — malgré la note de dépréciation de `Configuration.SetTimeZone` qui dit d'utiliser celui-là. Suivre la note aurait donné « No such method ». CONFIRMÉ EN VRAI : le moteur a suivi SANS redémarrage de nymead. Ce n'était jusqu'ici mesuré qu'en conteneur avec un programme Qt6 ; `GetEnergyRatios.timeZone` et `System.GetTime.timeZone` sont passés à Europe/Paris au cycle suivant, et `periodStartedAt` a reculé de 23:00 à 22:00 UTC. ET LA PAIRE A SERVI AU MOMENT EXACT OÙ ELLE SERVAIT. `measuredSince` n'a pas bougé (05:04:29 UTC) : la frontière publiée a changé, la portée réelle de la mesure non. Sans le second champ, le bilan du jour aurait paru couvrir une heure de plus qu'il ne couvre — un décalage introduit par la correction elle-même, le lendemain du jour où on a posé de quoi le voir. --- docs/DESIGN_FUSEAU.md | 33 +++++++++++++++++++++++++++++---- 1 file changed, 29 insertions(+), 4 deletions(-) diff --git a/docs/DESIGN_FUSEAU.md b/docs/DESIGN_FUSEAU.md index d048dcc..f2bc5ac 100644 --- a/docs/DESIGN_FUSEAU.md +++ b/docs/DESIGN_FUSEAU.md @@ -145,8 +145,33 @@ c'est au client de rapprocher cela de l'heure de son utilisateur, et de l'averti moment de la SAISIE d'une échéance, et avertir. C'est l'écran de saisie qui doit parler, pas l'écran de résultat — au moment du résultat, l'heure est déjà passée. -### Ce qui reste ouvert, et qu'on ne tranche pas ici +### Le fuseau de `.75` — corrigé le 2026-09-05, et la date compte -Le fuseau de `.75` lui-même. `Europe/London` sur un banc français est une erreur de -configuration, mais la corriger déplace d'une heure la lecture de tout l'historique -d'énergie déjà enregistré. C'est une décision d'exploitation, pas de conception. +`Europe/London` sur un banc français était une erreur de configuration. La correction a été +**différée** tant que le décalage n'était pas visible : la déplacer d'une heure sans rien qui le +dise aurait rendu l'historique illisible de part et d'autre, sans qu'aucun lecteur ne puisse +savoir où passait la couture. `periodStartedAt` a levé cette réserve — le décalage se lit +désormais dans la charge utile. + +**LA COUTURE, à retenir pour toute lecture de l'historique énergie de `.75` :** + +| | | +|---|---| +| **Instant du changement** | `2026-09-05T06:53:30Z` — soit 07:53:30 heure box AVANT, 08:53:30 APRÈS | +| **Avant** | `Europe/London` — journée de reporting de 23:00 UTC à 23:00 UTC | +| **Après** | `Europe/Paris` — journée de reporting de 22:00 UTC à 22:00 UTC | +| **Méthode** | `Configuration.SetTimeZone` en JSON-RPC (`System.SetTimeZone` n'existe pas en 1.15.2, malgré ce que dit sa propre note de dépréciation) | + +**Tout enregistrement antérieur à cet instant a ses frontières de journée une heure plus tard +que les suivants.** Une comparaison jour à jour qui franchit la couture compare deux découpages +différents. + +**Ce que la correction a confirmé, en vrai.** Le moteur a suivi **sans redémarrage de `nymead`** — +ce qui n'était jusque-là mesuré qu'en conteneur (§3). `GetEnergyRatios.timeZone` et +`System.GetTime.timeZone` sont passés à `Europe/Paris` au cycle suivant, et `periodStartedAt` a +reculé de 23:00 à 22:00 UTC. + +**Et la paire a joué son rôle au moment exact où elle servait.** `measuredSince` n'a PAS bougé +(05:04:29 UTC, le redémarrage du déploiement de la veille) : la frontière publiée a changé, la +portée réelle de la mesure non. Sans le second champ, le bilan du jour aurait paru couvrir une +heure de plus qu'il ne couvre — un décalage introduit par la correction elle-même.