Primeiro, reconheça que na terminologia moderna você deve dizer UTC em vez de GMT. Eles são principalmente equivalentes, exceto que o UTC é definido com mais precisão. Reserve o termo GMT para se referir à parte do fuso horário no Reino Unido que está em vigor durante os meses de inverno com o deslocamento UTC+0.
Agora a sua pergunta. O UTC não é necessariamente a melhor maneira de armazenar todos os valores de data e hora. Funciona particularmente bem para passados eventos, ou para futuros absolutos eventos, mas não funciona tão bem para futuros local eventos - especialmente futuros recorrentes eventos.
Eu escrevi sobre isso em outra resposta recentemente, e é um dos poucos casos de exceção em que a hora local faz mais sentido que o UTC. O principal argumento é o "problema do despertador". Se você definir seu despertador pelo UTC, acordará uma hora mais cedo ou mais tarde no dia das transições do horário de verão. É por isso que a maioria das pessoas ajusta seus despertadores pela hora local.
Claro, você não pode apenas armazene uma hora local se estiver trabalhando com dados de todo o mundo. Você deve armazenar algumas coisas diferentes:
- A hora local do evento recorrente, como "08:00"
- O fuso horário no qual a hora local é expressa, como "América/Nova_York"
- O padrão de recorrência, em qualquer formato que faça sentido para seu aplicativo, como diário, quinzenal ou na terceira quinta-feira do mês etc.
- O próximo imediato Data e hora UTC equivalentes, da melhor maneira possível.
- Talvez, mas nem sempre, uma lista de datas e horários UTC de eventos futuros, projetada em algum período predefinido no futuro (talvez uma semana, talvez 6 meses, talvez um ano ou dois, dependendo de suas necessidades). l>
Para os dois últimos, entenda que o equivalente UTC de qualquer data/hora local pode mudar se o governo responsável por esse fuso horário decidir alterar alguma coisa. Como há várias atualizações de banco de dados de fuso horário todos os anos, convém ter um plano para assine os anúncios de atualizações e atualize seu banco de dados de fuso horário regularmente. Sempre que você atualizar seus dados de fuso horário, precisará recalcular os horários equivalentes em UTC de todos os eventos futuros.
Ter os equivalentes UTC é importante se você planeja mostrar qualquer tipo de lista de eventos abrangendo mais de um fuso horário. Esses são os valores que você consultará para construir essa lista.
Outro ponto a considerar é que, se um evento for agendado para um horário local que ocorra durante uma transição de fallback do horário de verão, você terá que decidir se o evento ocorre na primeira instância (geralmente) ou na segunda instância (às vezes), ou ambos (raramente), e construa em seu aplicativo um mecanismo para garantir que o evento não seja disparado duas vezes, a menos que você queira.
Se você estava procurando uma resposta simples - desculpe, mas não há uma. Agendar eventos futuros em fusos horários é uma tarefa complicada.
Abordagem alternativa
Algumas pessoas me mostraram uma técnica em que fazem use a hora UTC para agendamento, que é escolher uma data de início na hora local, convertê-la em UTC a ser armazenada e armazenar o ID do fuso horário também. Em seguida, no tempo de execução, eles aplicam o fuso horário para converter a hora UTC original de volta para a hora local e, em seguida, usam essa hora local para calcular as outras recorrências, como se fosse a originalmente armazenada como acima.
Embora esta técnica funcione , as desvantagens são:
-
Se houver uma atualização de fuso horário que altere a hora local antes que a primeira instância seja executada, isso interromperá todo o agendamento. Isso pode ser mitigado escolhendo um tempo no passado para a "primeira" instância, de modo que a segunda instância seja realmente a primeira.
-
Se a hora for realmente um "tempo flutuante" que deve seguir o usuário (como em um despertador em um telefone celular), você ainda terá que armazenar informações de fuso horário para a zona em que foi originalmente criada - mesmo que essa não é a zona em que você quer correr.
-
Acrescenta complexidade adicional sem qualquer benefício. Eu reservaria essa técnica para situações em que você pode ter um agendador somente UTC no qual está tentando adaptar o suporte ao fuso horário.
