O hub segue a regra do seu fuso horário e muda o próprio relógio. Não se perde nada, nada é contado duas vezes e os preços ficam associados às horas certas.
Vale a pena conhecer o detalhe, porque a mudança afeta três coisas ao mesmo tempo: o relógio, os registos e as zonas tarifárias.
Como o hub sabe da mudança
Guarda a regra completa do fuso horário, não um desvio fixo: uma cadeia como CET-1CEST,M3.5.0,M10.5.0/3, que contém as datas de transição. As predefinições em Settings → Time para zonas europeias e dos EUA são regras deste tipo, por isso um hub configurado com uma predefinição trata da mudança sozinho, todos os anos, sem que tenha de fazer nada em março ou outubro.
Dois pontos a vigiar:
- Um desvio fixo nunca muda. Se o fuso do hub for introduzido como um simples desvio, mantém-no o ano inteiro. Só a cadeia de regra decide; use, por isso, uma predefinição ou introduza uma regra válida. (Na app v1.1.4 e anteriores, o editor de configuração em bruto mostrava também um indicador Daylight saving que não tinha efeito algum. Foi retirado precisamente por isso.)
- As zonas do hemisfério sul com horário de verão estão na lista de predefinições — Sydney/Melbourne/Canberra/Hobart, Adelaide, Brisbane, Perth, Auckland/Wellington, Santiago, São Paulo/Buenos Aires, Johannesburg — e a app deteta-as a partir do navegador como todas as outras. Na app v1.1.4 e anteriores não eram oferecidas: o hub tratava bem as suas regras, mas era preciso escrever à mão uma cadeia POSIX TZ.
O que acontece aos registos
Os registos horários são indexados por UTC, e é isso que mantém a noite organizada:
- No outono, a hora local repetida corresponde a duas horas UTC diferentes, por isso obtém dois registos separados: ambos guardados, nenhum substitui o outro.
- Na primavera, nenhuma hora falta nos dados. A etiqueta local salta simplesmente de 01:59 para 03:00.
Os registos diários, semanais e mensais seguem o seu calendário local. Assim, o dia da mudança tem mesmo 23 horas na primavera e 25 no outono, e a semana e o mês que o contêm ficam uma hora mais curtos ou mais longos. Isto está correto, não é uma falha: é o tempo que realmente passou.
Um efeito visível: um gráfico horário em hora local mostra uma etiqueta de hora duas vezes no outono, e salta uma na primavera.
O que acontece ao custo
Cada período de 15 minutos é valorizado pela hora local do seu ponto médio, para que a energia receba sempre o fuso em que caiu realmente.
Para uma zona noturna das 23:00 às 07:00, a janela dura nove horas na noite de outono e sete na de primavera. A hora repetida no outono é energia real e fatura-se à tarifa noturna, como a hora anterior.
O único ponto áspero: um limite de zona colocado dentro da hora que se repete ou desaparece (uma janela que termina às 02:30, por exemplo) ficará ativo duas vezes nessa meia hora no outono, e na primavera a sua fronteira cai às 03:00. Os limites de hora certa fora de 02:00–03:00, que são quase todas as tarifas reais, não são afetados.
E os contadores diários
Repõem-se à meia-noite local, que a mudança não desloca: as transições europeias e americanas acontecem entre as 01:00 e as 03:00. Os totais do dia cobrem então 23 ou 25 horas de energia real, e o marcador de dia do hub traz o novo desvio a partir do dia seguinte.
Na app v1.1.4 e anteriores havia aqui um desvio visível: nesses dois dias, os valores de today da app começavam uma hora antes, a partir do momento em que o relógio mudava, de modo que “today” incluía em silêncio uma hora da noite anterior. Os registos estavam certos; o que se lia na Overview era uma hora mais largo. Corrigido desde a v1.1.5, em que “today” começa à meia-noite real do hub nos dois dias de mudança.
Verificado com os autotestes do firmware, que executam o código de registos e preços com datas reais de transição de Berlim, Nova Iorque e Sydney. Não observado numa mudança real.