El hub sigue la regla de su zona horaria y cambia su propio reloj. No se pierde nada, no se cuenta nada dos veces y los precios siguen asociados a las horas correctas.
Los detalles merecen la pena, porque el cambio afecta a tres cosas a la vez: el reloj, los registros y las zonas tarifarias.
Cómo sabe el hub del cambio
Guarda la regla completa de la zona horaria, no un desfase fijo: una cadena como CET-1CEST,M3.5.0,M10.5.0/3, que contiene las fechas de transición. Las preconfiguraciones de Settings → Time para zonas europeas y de EE. UU. son reglas de este tipo, así que un hub configurado con una preconfiguración gestiona el cambio por sí mismo, cada año, sin que usted tenga que hacer nada en marzo u octubre.
Dos cosas que vigilar:
- Un desfase fijo nunca cambia. Si la zona del hub se introduce como un desfase simple, lo mantiene todo el año. Solo decide la cadena de regla, así que use una preconfiguración o introduzca una regla correcta. (En la app v1.1.4 y anteriores, el editor de configuración en bruto también mostraba un indicador Daylight saving que no tenía ningún efecto. Se eliminó precisamente por eso.)
- Las zonas del hemisferio sur con horario de verano están en la lista de preconfiguraciones — Sydney/Melbourne/Canberra/Hobart, Adelaide, Brisbane, Perth, Auckland/Wellington, Santiago, São Paulo/Buenos Aires, Johannesburg —, y la app las detecta desde su navegador como cualquier otra. En la app v1.1.4 y anteriores no se ofrecían: el hub manejaba bien sus reglas, pero había que escribir a mano una cadena POSIX TZ.
Qué pasa con los registros
Los registros horarios se indexan por UTC, y eso es lo que mantiene ordenada la noche:
- En otoño, la hora local repetida corresponde a dos horas UTC distintas, así que hay dos registros separados: ambos se conservan y ninguno sobrescribe al otro.
- En primavera no falta ninguna hora en los datos. La etiqueta local simplemente salta de 01:59 a 03:00.
Los registros diarios, semanales y mensuales siguen su calendario local. Por eso el día del cambio dura de verdad 23 horas en primavera y 25 en otoño, y la semana y el mes que lo contienen son una hora más cortos o más largos. Es correcto, no un error: es la cantidad de tiempo que realmente ha pasado.
Un efecto visible: un gráfico horario en hora local muestra una etiqueta de hora dos veces en otoño, y salta una en primavera.
Qué pasa con el coste
Cada periodo de 15 minutos se valora según la hora local de su punto medio, de modo que la energía siempre recibe la zona en la que realmente cayó.
Para una zona nocturna de 23:00 a 07:00, la ventana dura nueve horas en la noche de otoño y siete en la de primavera. La hora repetida en otoño es energía real y se factura a la tarifa nocturna, igual que la hora anterior.
El único punto delicado: un límite de zona situado dentro de la hora que se repite o desaparece —una ventana que termina a las 02:30, por ejemplo— estará activo dos veces durante esa media hora en otoño, y en primavera su borde cae a las 03:00. Los límites en hora exacta fuera de 02:00–03:00, que son casi todas las tarifas reales, no se ven afectados.
Y los contadores diarios
Se reinician a medianoche local, y el cambio no mueve esa medianoche: las transiciones europeas y estadounidenses ocurren entre las 01:00 y las 03:00. Los totales del día cubren entonces 23 o 25 horas de energía real, y el marcador de día del hub lleva el nuevo desfase desde el día siguiente.
En la app v1.1.4 y anteriores había aquí un fallo visible: en esos dos días, las cifras de today de la app empezaban una hora antes, desde el momento en que cambiaba el reloj, así que “today” incluía en silencio una hora de la noche anterior. Los registros en sí eran correctos; lo que se leía en la Overview era una hora más ancho. Corregido desde la v1.1.5, donde “today” empieza a la medianoche real del hub en ambos días del cambio.
Verificado con los autotests del firmware, que ejecutan el código de registros y precios con fechas reales de transición de Berlín, Nueva York y Sydney. No observado en un cambio de hora real.