Lagra tidsinformation:Tidszon krävs?

Oavsett vilket sätt du gör det kommer det att misslyckas på olika sätt beroende på vad som förändras.

1. Om du lagrar tidsstämplar i motsvarande tidszon som 2013-12-29 12:34:56 America/New_York , kommer detta att misslyckas om, säg, Bronx plötsligt startar sin egen tidszon America/New_York_Bronx med en annan offset och ditt evenemang råkade vara i Bronx.

   Bestäm hur troligt detta är och hur illa ett misslyckande skulle vara.

2. Om du lagrar tidsstämplar i UTC och tidszonen där händelsen äger rum omdefinierar deras offset (t.ex. skiftar sommartid, eller helt skiftar till en annan offset), kan händelsetiden skilja sig från den faktiska väggklockan på den platsen. Om du lagrar 2013-12-29 12:34:56 UTC för ett evenemang kl. 13:34:56 i Berlin, Tyskland, och Berlin flyttar sin sommartid runt, 2013-12-29 12:34:56 UTC kan nu motsvara 14:34:56 Berlin lokal tid, medan evenemanget fortfarande faktiskt äger rum 13:34 lokal tid.

   Bestäm hur troligt detta är och hur illa ett misslyckande skulle vara.

3. Om du lagrar UTC-tidsstämpeln och länkar den till en fysisk plats som du sedan länkar till en tidszon kan du motverka båda problemen. Men för detta måste du lagra den exakta fysiska platsen, inte bara "New York", annars har du bara fall 1. med ytterligare ett mellansteg. Om du lagrar den exakta fysiska platsen och har ett exakt sätt att lösa denna plats till en tidszon och du håller din tidszondatabas uppdaterad, kan du hantera i stort sett alla förändringsscenarier.

   Bestäm hur praktiskt detta är och hur mycket denna extra precision är värd för dig.