b843d8936a
Trouvé sur appareil pendant la bascule volontaire de .75 en Europe/London, en capturant la ligne d'horloge de l'échéance : la box publie `measuredSince: "2026-09-06T14:38:00Z"` et l'écran affichait « mesuré depuis 14:38 » — ni l'heure de la box (15:38 BST), ni celle du téléphone (16:38 CEST). L'heure de personne. `DateTime.tryParse` d'une chaîne en `Z` rend un DateTime `isUtc: true` ; lire `.hour` sans `toLocal()` donne l'heure UTC. Le défaut est identiquement invisible tant que box et appareil partagent l'offset : il a fallu DEUX fuseaux pour qu'il se voie, et c'est la couture ouverte pour la capture qui l'a montré. Deux natures d'heure, désormais séparées dans CLAUDE.md : - un RÉGLAGE (`dailyDeadline`) est lu par la box → on nomme son horloge ; - un INSTANT (`measuredSince`) est absolu → il se rend chez le lecteur, sans mention. Les deux tests qui gardaient « 03:42 » en dur gelaient l'heure UTC et validaient le défaut : leur attendu se dérive maintenant de `.toLocal()`. Le contrôle négatif ne mord que hors UTC, et le test le dit au lieu de laisser lire un vert comme une preuve. Capture de la ligne d'horloge : docs/captures/2026-09-06_fuseau-box-london.png Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GKM8FDNHZWogAsjjfB8pSw
etm_powersync_app
A new Flutter project.
Getting Started
This project is a starting point for a Flutter application.
A few resources to get you started if this is your first Flutter project:
For help getting started with Flutter development, view the online documentation, which offers tutorials, samples, guidance on mobile development, and a full API reference.