Uma aplicação em contentor pode reverter para UTC após uma atualização quando a nova imagem remove os dados de fusos horários, ignora TZ ou deixa de utilizar a montagem do fuso horário do anfitrião.
O relógio do anfitrião pode continuar correto enquanto a aplicação formata as datas em UTC, porque os contentores normalmente partilham o relógio do kernel do anfitrião, mas têm os seus próprios ficheiros de fuso horário, ambiente e dados do runtime da linguagem. Uma atualização da imagem pode mudar a distribuição base, remover o tzdata, altere o utilizador da aplicação, substitua o ponto de entrada ou deixe de respeitar um TZ variável. Compare a imagem antiga e a nova antes de alterar o fuso horário do anfitrião.
Separe a hora do relógio do sistema da formatação do fuso horário
Registe a hora UTC, a hora local formatada, o nome do fuso horário, o desfasamento numérico e a hora apresentada pela própria aplicação dentro dos contentores antigo e novo.
A GNU C Library explica que a variável TZ controla a conversão da hora local, enquanto o relógio de sistema subjacente continua a ser uma fonte de tempo absoluto.
Se a hora de época corresponder, mas o fuso apresentado mudar, o problema está na configuração do fuso horário e não num desfasamento do relógio ou no NTP.
Verifique se a nova imagem ainda contém o tzdata
Compare os pacotes instalados, /usr/share/zoneinfo, /etc/localtime, e /etc/timezone entre as etiquetas de imagem anterior e atual.
O pacote tzdata do Debian fornece definições de fusos horários utilizadas pelas aplicações para converter UTC na hora local regional.
Uma imagem de substituição minimalista pode omitir intencionalmente este pacote. Instale-o numa imagem derivada ou utilize o mecanismo de fuso horário suportado pela aplicação, em vez de modificar manualmente um contentor em execução.
Verifique como a distribuição base aplica o fuso horário
Identifique se a imagem é Debian, Ubuntu, Alpine, distroless ou outra base. Não presuma que a configuração TZ tem efeitos idênticos em todas as imagens.
O Alpine Linux documenta a configuração do fuso horário através do tzdata e do zoneinfo.
Se a atualização tiver alterado a imagem base, repita a configuração do fuso horário utilizando o método suportado por essa distribuição. Copiar um único ficheiro do contentor antigo pode deixar as regras de horário de verão desatualizadas.
Inspecionar o bind mount localtime do anfitrião
Compare os mounts do contentor em execução antes e depois da recriação. Verifique se /etc/localtime ou um ficheiro zoneinfo continua montado como só de leitura.
Os bind mounts do Docker mapeiam um ficheiro ou diretório exato do anfitrião para o contentor. As orientações oficiais sobre bind mounts explicam por que motivo um mount do Compose removido ou um caminho de origem alterado faz com que o novo contentor recorra à predefinição da imagem.
Não monte todo o /etc diretório. Utilize o ficheiro suportado específico ou a configuração explícita de fuso horário exigida pela aplicação.
Verificar a própria base de dados de fusos horários do runtime da aplicação
Identifique se a aplicação utiliza a base de dados zoneinfo do sistema operativo ou inclui dados de fusos horários no Python, Java, PHP, Node.js ou outro runtime.
O módulo zoneinfo do Python procura dados do sistema ou um pacote tzdata.
Uma aplicação pode, por isso, apresentar UTC mesmo quando os comandos da shell mostram o fuso horário correto. Compare separadamente o comportamento em execução da aplicação com o da shell do contentor.
Verificar a precedência das variáveis de ambiente do Compose após a recriação
Inspecione o ambiente final do contentor recriado e compare-o com a interpolação do Compose, ambiente, env_file, e predefinições de imagens.
A documentação de contentores da Red Hat indica que a configuração do ambiente de execução pode substituir o ambiente da imagem, pelo que uma imagem atualizada e um ficheiro de implementação antigo podem produzir um valor final diferente do esperado.
Consulte o ambiente real do contentor, em vez de apenas o ficheiro Compose. Uma interface de pilha desatualizada ou um ficheiro de ambiente alternativo pode ter recriado o serviço sem a variável de fuso horário pretendida.
Fixe a configuração e teste numa atualização posterior
Escolha um método de fuso horário suportado, fixe-o na configuração de implementação controlada por versões, recrie o contentor e verifique as datas de inverno e de horário de verão, quando aplicável.
O artigo da ZimaSpace sobre a hora das tarefas do contentor e o ambiente fornece o limite de diagnóstico adjacente para agendamentos que mudam quando as definições de hora do contentor são alteradas.
O problema fica resolvido quando a aplicação, a shell, os registos e as tarefas agendadas utilizam o fuso pretendido após o reinício e uma nova recriação controlada da imagem.
Perguntas frequentes
Os contentores têm o seu próprio relógio de hardware?
Não. Normalmente partilham o relógio do kernel do anfitrião, mas podem formatar essa hora utilizando dados de fuso horário e definições de ambiente diferentes.
Definir TZ é sempre suficiente?
Não. A imagem e a aplicação têm de suportar a variável e ter acesso às regras de fuso horário. Alguns ambientes de execução utilizam uma base de dados própria incluída no pacote.
Devo alterar o fuso horário do anfitrião NAS para corrigir um contentor?
Não. Primeiro corrija a configuração do contentor ou da aplicação; alterar o anfitrião pode afetar os registos, os agendamentos e todos os outros serviços.
Suporte e Dicas
Mais para Ler

Por que motivo o restauro de um volume Docker recria o conteúdo dos ficheiros, mas elimina os atributos estendidos?
Um diagnóstico da restauração de volumes que abrange o inventário de xattr, as opções do tar e do Rsync, os namespaces, o suporte do...

Porque é que um contentor em execução mantém o limite de memória antigo depois de o ficheiro Compose ser alterado?
Um diagnóstico dos limites de memória que abrange cgroups ativos, reinício versus recriação, campos do Compose, limites rígidos e flexíveis, âmbitos superiores, swap e...

Porque é que reiniciar um proxy reverso invalida todas as sessões de uma aplicação auto-hospedada?
Um diagnóstico da perda de sessão que abrange o âmbito do reinício, a propriedade dos cookies, a rotação de segredos, as sessões suportadas por...

