Przechowywanie informacji o czasie:wymagana strefa czasowa?

Niezależnie od tego, jak to zrobisz, zawiedzie na różne sposoby, w zależności od tego, co się zmienia.

1. Jeśli przechowujesz znaczniki czasu w odpowiedniej strefie czasowej jako 2013-12-29 12:34:56 America/New_York , to się nie powiedzie, jeśli, powiedzmy, Bronx nagle uruchomi swoją własną strefę czasową America/New_York_Bronx z innym offsetem, a Twoje wydarzenie akurat miało miejsce na Bronksie.

   Zdecyduj, jakie jest to prawdopodobieństwo i jak poważna byłaby awaria.

2. Jeśli przechowujesz sygnatury czasowe w czasie UTC, a strefa czasowa, w której odbywa się wydarzenie, zmienia ich przesunięcie (np. przesunięcie dat czasu letniego lub całkowite przesunięcie do innego przesunięcia), czas wydarzenia może różnić się od rzeczywistego czasu na zegarze ściennym w tej lokalizacji. Jeśli zapiszesz 2013-12-29 12:34:56 UTC w przypadku wydarzenia o 13:34:56 w Berlinie w Niemczech, a Berlin zmienia swój czas letni, 2013-12-29 12:34:56 UTC może teraz odpowiadać 14:34:56 czasu lokalnego w Berlinie, podczas gdy wydarzenie nadal ma miejsce o 13:34 czasu lokalnego.

   Zdecyduj, jakie jest to prawdopodobieństwo i jak poważna byłaby awaria.

3. Jeśli przechowujesz znacznik czasu UTC i łączysz go z fizyczną lokalizacją, którą następnie łączysz ze strefą czasową, możesz przeciwdziałać obu problemom. Ale w tym celu będziesz musiał zapisać dokładną fizyczną lokalizację, a nie tylko „Nowy Jork”, w przeciwnym razie masz tylko przypadek 1. z jeszcze jednym krokiem pośrednim. Jeśli przechowujesz dokładną lokalizację fizyczną i masz precyzyjny sposób na przekształcenie tej lokalizacji w strefę czasową i aktualizujesz bazę danych stref czasowych, możesz obsłużyć prawie wszystkie scenariusze zmian.

   Zdecyduj, na ile jest to praktyczne i ile ta dodatkowa precyzja jest dla Ciebie warta.