Estou curioso para saber se o que estou considerando é uma má prática ou, se essa é uma escolha específica e deliberada, é realmente uma ideia decente. Quero armazenar informações de datas para eventos que ocorrem em cidades específicas. Quero armazenar esses dados como carimbos de data e hora UTC. Não seria uma boa idéia simplesmente armazenar o registro de data e hora / código da cidade / país (associado a um fuso horário específico), em vez de armazenar o fuso horário para cada evento? Pergunto porque os fusos horários podem mudar, mas os IDs da cidade nunca mudariam no banco de dados. Depois que o servidor for sincronizado com o fuso horário mais recente no evento (improvável) de uma alteração de fuso horário, o evento será independente e não será afetado por essa alteração. No entanto, digamos que um fuso horário mude seus limites, os eventos que ocorreram naquele fuso horário anteriormente poderiam estar fora dele. Parece imprudente fazer isso? Só estou pensando e tenho procurado as melhores práticas, mas, neste caso, isso realmente parece uma boa idéia. Isso funciona particularmente porque o modelo de design do aplicativo nunca mudaria - os eventos SEMPRE serão associados a uma cidade específica.

O fluxo básico seria:

Os dados do evento com data / local entram no sistema em um formato padrão como a sequência ISO-8601 AAAA-MM-DD.

O sistema converte a data em carimbo de data / hora UTC e armazena a data com o evento usando esse carimbo de data e hora e o ID da cidade para o evento.

Quando um usuário solicita a exibição desse evento, o sistema obtém o carimbo de data e hora das informações da cidade associadas a esse evento e usa o fuso horário da cidade para formatar a data de acordo.

Esta é uma ideia terrível? Existe um benefício nisso e o conceito de armazenar o TZ Offset é a mesma idéia para eliminar esse problema?