Estou na zona da UE +1 ou quando o horário de verão está ativado, +2. Agora é domingo, 31.3.2024. Na manhã deste domingo, mudamos para horário de verão, às 2→3 ( CET → CEST ).
Tenho servidores Linux em redes separadas informando o consumo mensal de energia às 23h58 do último dia do mês. Eles funcionaram perfeitamente por muitos anos. As redes estão separadas por até 8 horas de viagem!
Cada servidor possui um RTC e sincroniza o NTP regularmente. Existem muitas proteções caso algo seja suspeito, e três servidores principais em cada rede verificam constantemente entre si se tudo, incluindo a hora, está OK. Sim, sou paranóico. Não tolero nenhum (0) bug. Meus sistemas funcionam perfeitamente estáveis por muitos anos. Funcionou, desculpe.
Ontem à noite, às 23h58 do dia 30 de março, todos os meus servidores Raspberry Pi decidiram que o dia 30 de março será seguido pelo dia 1º do próximo mês! Verifiquei de 7 (sete) maneiras diferentes e independentes por cada rede, que tudo realmente ocorreu no dia 30 de março no minuto 23h58! A confirmação inclui 9 dispositivos separados que ignoram o horário de verão, além de um provedor de correio externo dos EUA e da UE.
Às 23h58 de cada dia, meus servidores fazem um teste bash que aparentemente pode dar errado de várias maneiras:
(( $(date -d tomorrow +"%-d") == 1 )) && ZadnjiDanMjeseca=1 || ZadnjiDanMjeseca=""
Não vejo nenhuma maneira desse teste dar errado! Espero estar errado. Neste momento em 31.3.2024. Tudo funciona perfeitamente bem e o zdump está correto! (O exemplo a seguir parece formatado incorretamente para mim. Deve haver quatro linhas distintas mostradas.)
hwclock; date; date -d tomorrow +"%-d"
2024-03-31 19:22:23.311664+02:00
ned, 31.03.2024. 19:22:23 CEST
1
A única maneira de explicar esse problema é: A distribuição Linux que uso, Raspbian , de alguma forma tem duas funções de kernel separadas para calcular o tempo. Um deles, infelizmente, não percebeu que este é um ano bissexto! Ups!
Mas, em caso afirmativo, por que deveria ser limitado a esta versão e kernel do sistema operacional Raspberry Pi? Inferno, a Microsoft não conseguiu fazer o Excel calcular os anos bissextos corretamente!
Durante este fim de semana, vi várias instituições (bancos, a nossa administração fiscal nacional...) no meu país tendo problemas relacionados com datas e fechando a loja também, por isso parece não estar limitado ao Raspbian.
Isso vai contra mim como programador, mas não consigo encontrar nenhuma explicação alternativa. Espero que eu esteja errado...
Antes de postar, mudei das 23h58 para as 00h03 do dia 1º, e onde devo registrar os dados às 23h58 do último dia do mês, faço o teste adicionando 300 segundos, não pedindo +1 dia. Essas soluções devem funcionar.
Portanto, não está enterrado nos comentários: como nunca uso esses cálculos, cometi um erro básico ao esperar que “amanhã” na verdade significa amanhã! Não faz nenhum sentido para mim; significa +1 dia. Então, esperava que esses dois comandos produzissem a mesma saída:
> date -d 'next tue'
uto, 2.04.2024. 00:00:00 CEST
> date -d 'tomorrow'
uto, 2.04.2024. 10:24:55 CEST
em vez de ter que digitar:
date -d "tomorrow 0"