Lagring af tidsoplysninger:Tidszone påkrævet?

Uanset hvordan du gør det, vil det fejle på forskellige måder afhængigt af, hvad der ændrer sig.

1. Hvis du gemmer tidsstempler i den tilsvarende tidszone som 2013-12-29 12:34:56 America/New_York , vil dette mislykkes, hvis f.eks. Bronx pludselig starter deres egen tidszone America/New_York_Bronx med en anden offset, og din begivenhed var tilfældigvis i Bronx.

   Beslut hvor sandsynligt dette er, og hvor slemt en fiasko ville være.

2. Hvis du gemmer tidsstempler i UTC, og tidszonen, hvor begivenheden finder sted, omdefinerer deres forskydning (f.eks. skifter sommertidsdatoer eller helt skifter til en anden forskydning), kan begivenhedstiden afvige fra det faktiske vægurs tid på det pågældende sted. Hvis du gemmer 2013-12-29 12:34:56 UTC til en begivenhed kl. 13:34:56 i Berlin, Tyskland, og Berlin skifter sommertid, 2013-12-29 12:34:56 UTC kan nu svare til 14:34:56 Berlin lokal tid, mens begivenheden stadig faktisk foregår kl. 13:34 lokal tid.

   Beslut hvor sandsynligt dette er, og hvor slemt en fiasko ville være.

3. Hvis du gemmer UTC-tidsstemplet og knytter det til en fysisk lokation, som du derefter linker til en tidszone, kan du modvirke begge problemer. Men for dette bliver du nødt til at gemme den præcise fysiske placering, ikke kun "New York", ellers har du bare sag 1. med endnu et mellemtrin. Hvis du gemmer den præcise fysiske placering og har en præcis måde at omsætte denne placering til en tidszone, og du holder din tidszonedatabase opdateret, kan du håndtere stort set alle ændringsscenarier.

   Beslut hvor praktisk dette er, og hvor meget denne ekstra præcision er værd for dig.