Der Hub folgt der Regel Ihrer Zeitzone und stellt seine Uhr selbst um. Nichts geht verloren, nichts wird doppelt gezählt, und die Preise bleiben den richtigen Stunden zugeordnet.
Die Details lohnen sich trotzdem, denn die Umstellung betrifft drei Dinge gleichzeitig: die Uhr, die Datensätze und die Tarifzonen.
Woher der Hub von der Umstellung weiß
Er speichert die vollständige Zeitzonen-Regel, keinen festen Offset — eine Zeichenkette wie CET-1CEST,M3.5.0,M10.5.0/3, die die Umstellungstermine enthält. Die Voreinstellungen unter Settings → Time für europäische und US-Zonen sind Regeln dieser Art. Ein Hub, der mit einer Voreinstellung eingerichtet ist, übernimmt die Umstellung deshalb jedes Jahr selbst, ohne dass Sie im März oder Oktober etwas tun müssen.
Zwei Dinge sind zu beachten:
- Ein fester Offset ändert sich nie. Wenn die Zeitzone des Hubs als reiner Offset eingetragen ist, behält er ihn das ganze Jahr. Nur die Regel-Zeichenkette entscheidet. Verwenden Sie also eine Voreinstellung oder geben Sie eine gültige Regel ein. (In App-Version v1.1.4 und früher zeigte der Rohkonfigurations-Editor außerdem ein Flag Daylight saving, das keine Wirkung hatte. Es wurde aus genau diesem Grund entfernt.)
- Zonen der Südhalbkugel mit Sommerzeit stehen in der Voreinstellungsliste — Sydney/Melbourne/Canberra/Hobart, Adelaide, Brisbane, Perth, Auckland/Wellington, Santiago, São Paulo/Buenos Aires, Johannesburg —, und die App erkennt sie wie alle anderen über den Browser. In App-Version v1.1.4 und früher wurden sie nicht angeboten: Der Hub behandelte ihre Regeln korrekt, Sie mussten aber eine POSIX-TZ-Zeichenkette von Hand eintippen.
Was mit den Datensätzen passiert
Stündliche Datensätze sind nach UTC indiziert, und genau das hält die Nacht übersichtlich:
- Im Herbst entspricht die doppelt vorkommende lokale Stunde zwei verschiedenen UTC-Stunden. Sie erhalten also zwei getrennte Datensätze — beide bleiben erhalten, keiner überschreibt den anderen.
- Im Frühjahr fehlt in den Daten keine Stunde. Die lokale Beschriftung springt einfach von 01:59 auf 03:00.
Tages-, Wochen- und Monatsdatensätze folgen Ihrem lokalen Kalender. Der Umstellungstag dauert daher tatsächlich 23 Stunden im Frühjahr und 25 im Herbst, und die Woche und der Monat, die ihn enthalten, sind eine Stunde kürzer bzw. länger. Das ist richtig und kein Fehler: Es ist genau so viel Zeit vergangen.
Eine sichtbare Nebenwirkung: Ein stündliches Diagramm in Ortszeit zeigt im Herbst eine Stundenbeschriftung zweimal und lässt im Frühjahr eine aus.
Was mit den Kosten passiert
Jede 15-Minuten-Periode wird nach der Ortszeit ihrer Mitte bepreist. So erhält die Energie immer die Zone, in die sie tatsächlich fiel.
Bei einer Nachtzone von 23:00–07:00 dauert das Fenster in der Herbstnacht also neun Stunden und in der Frühjahrsnacht sieben. Die doppelt vorkommende Stunde im Herbst ist echte Energie und wird zum Nachttarif berechnet, wie die Stunde davor.
Die eine raue Stelle: Eine Zonengrenze innerhalb der Stunde, die sich wiederholt oder verschwindet — etwa ein Fenster, das um 02:30 endet —, ist im Herbst für diese halbe Stunde zweimal aktiv, und im Frühjahr liegt ihr Rand bei 03:00. Volle Stundengrenzen außerhalb von 02:00–03:00, also fast jeder reale Tarif, sind nicht betroffen.
Und die Tageszähler
Sie werden um Mitternacht nach Ortszeit zurückgesetzt, und die Umstellung verschiebt diese Mitternacht nicht: Europäische und US-Umstellungen finden zwischen 01:00 und 03:00 statt. Die Tagessummen umfassen dann 23 oder 25 Stunden echter Energie, und die Tagesmarke des Hubs trägt ab dem Folgetag den neuen Offset.
In App-Version v1.1.4 und früher gab es hier einen sichtbaren Fehler: An den beiden Umstellungstagen begannen die today-Werte der App eine Stunde zu früh, schon mit dem Moment der Uhrumstellung. Dadurch enthielt „today“ still eine Stunde der Nacht davor. Die Datensätze selbst waren richtig; was Sie auf der Overview sahen, war um eine Stunde zu breit. Ab v1.1.5 behoben: „today“ beginnt an beiden Umstellungstagen um die echte Mitternacht des Hubs.
Geprüft anhand der Selbsttests der Firmware, die Datensatz- und Preislogik gegen die echten Umstellungstermine von Berlin, New York und Sydney laufen lassen. Nicht bei einer realen Umstellung beobachtet.