Seja qual for a maneira que você fizer isso, ele falhará de maneiras diferentes, dependendo do que está mudando.

1. 
   Se você armazenar carimbos de data/hora no fuso horário correspondente como 2013-12-29 12:34:56 America/New_York , isso falhará se, digamos, o Bronx de repente iniciar seu próprio fuso horário America/New_York_Bronx com um deslocamento diferente e seu evento aconteceu no Bronx.
   
   Decida qual é a probabilidade disso e quão ruim seria uma falha.
   
2. 
   Se você armazenar carimbos de data/hora em UTC e o fuso horário em que o evento está acontecendo estiver redefinindo seu deslocamento (por exemplo, mudando as datas do horário de verão ou mudando totalmente para um deslocamento diferente), o horário do evento pode ser diferente do horário real do relógio de parede nesse local. Se você armazenar 2013-12-29 12:34:56 UTC para um evento às 13:34:56 em Berlim, Alemanha, e Berlim muda o horário de verão, 2013-12-29 12:34:56 UTC pode agora corresponder às 14:34:56 hora local de Berlim, enquanto o evento ainda está acontecendo às 13:34 hora local.
   
   Decida qual é a probabilidade disso e quão ruim seria uma falha.
   
3. 
   Se você armazenar o carimbo de data/hora UTC e vinculá-lo a um local físico que você vinculará a um fuso horário, poderá neutralizar os dois problemas. Mas para isso você terá que armazenar a localização física precisa, não apenas "Nova York", caso contrário você só tem o caso 1. com mais uma etapa intermediária. Se você armazenar o local físico preciso e tiver uma maneira precisa de resolver esse local para um fuso horário e mantiver seu banco de dados de fuso horário atualizado, poderá lidar com praticamente todos os cenários de alteração.
   
   Decida como isso é prático e quanto vale essa precisão extra para você.