Devo (ainda) usar UTC para todos os meus servidores?

Existe algum bom motivo para (ainda) usar UTC como fuso horário do sistema?

Sim absolutamente! Considere um grande evento que acontece em 29 de outubro de 2023 às 02h30. As mensagens de log são devidamente geradas. (A relevância desta data/hora é que os relógios em toda a Europa atrasam uma hora naquela manhã, e para a mudança CEST/CET é às 3h da manhã.)

Se você estiver executando o UTC, os registros de data e hora não serão ambíguos ^* . Pode ser necessário converter para CEST/CET, mas você sabe com certeza o tempo absoluto. Por outro lado, se você estiver correndo no horário local, primeiro precisa tentar descobrir se esta foi a primeira ou a segunda vez no período das 02:00 às 03:00. Dependendo da quantidade de mensagens de log, isso pode não ser possível.

Os trabalhos cron costumavam ser um problema, mas usar CRON_TZou migrar para systemdunidades de cronômetro, conforme sugerido em outra resposta, resolverá isso perfeitamente.

^{* além do ocasional segundo bissexto, isto é, conforme mencionado por akostadinov}

Eu realmente entendo sua dor de leitura de log, mas não gostaria de discutir horários em arquivos de log com meus colegas americanos e alemães durante as cerca de 2 semanas por ano em que o horário de verão afetou um continente, mas não o outro¹. Pessoalmente, embora isso certamente não seja tão relevante para serviços que têm uso principalmente local (por exemplo, um servidor de impressão - não como alguém no Arizona imprimirá em minha impressora do sul da Alemanha), encontrei muito menos carimbos de data / hora UTC em logs de servidor de correio confuso.

Em relação aos seus trabalhos cron: estou lentamente tentando me livrar do bom e velho crontab, em favor de unidades de timer systemd. Eles têm um OnCalendar=campo e isso requer uma especificação de fuso horário ! Então, você ainda pode dizer, ei, incrível, às 7:00 da manhã em Berlim, pontapé inicial dessa transferência RFC 2324 ou qualquer outra coisa.

Em suma, sim, para um servidor, fique em UTC. Mas, com toda a franqueza, acho que a consistência é mais importante do que "a percepção da beleza administrativa de Müller" aqui. Se o resto do seu escopo administrativo/equipes adjacentes e usuários esperam CET, então: Vá CET. As coisas devem funcionar.

¹ Posso ser um outlier. Meu relógio de pulso mecânico também está em UTC.

Os servidores devem sempre armazenar UTC. A hora local é um problema da camada de apresentação que apenas os humanos precisam ver. Se você, como usuário, deseja ver alguns dados com data e hora, provavelmente deseja vê-los em seu fuso horário, independentemente do que o servidor pensa que é.

O UTC é inequívoco para todos (incluindo dias/segundos bissextos) e nunca se sobrepõe a qualquer horário de verão (exceto em circunstâncias excepcionais).

Os horários locais podem (e se sobrepõem) a cada 6 meses, portanto, se você estivesse olhando os logs que usaram o horário local como um carimbo de data/hora, março pareceria estar faltando essa hora e outubro teria essa hora duas vezes .

Você vê as desvantagens do UTC (difícil de traduzir mentalmente para a hora local). Você não vê as vantagens do UTC ou melhor, a falta de problemas: ter todos os servidores concordando com o horário é muito, muito valioso. Você descobriria muito rapidamente se mudasse seus servidores para algum horário local.

Mantenha seus servidores em UTC. Você pode considerar a criação de algumas ferramentas que ajudam a examinar os logs. Essa ferramenta pode, por exemplo, exibir datas na hora local. Ou agrupe logs juntos no tempo. Ou substitua ids ilegíveis de 32 bytes por "id1", "id2" etc. para saber quais linhas de log pertencem à mesma ação. Ou remova 1000 linhas de log quase idênticas.