Jak przechowywać datetimes w UTC i lokalnej strefie czasowej

Question

Jaki jest praktyczny sposób przechowywania dat w sieci, aby umożliwić użytkownikom przeglądanie/wysyłanie zapytań do danych w ich własnym czasie lokalnym przy zachowaniu informacji o pierwotnej datetime.

Zasadniczo użytkownicy chcą mieć możliwość wysyłania zapytań (według własnego czasu lokalnego) danych zebranych z systemów w różnych strefach czasowych. Czasami jednak chcą wiedzieć, że dane zostały utworzone na przykład na 18:00 w oryginalnym systemie. Pomaga, gdy użytkownicy z różnych części świata komunikują się o tym samym wydarzeniu.

User1: What? We don't have any data for 20:00 
User2: Dude, it says 20:00 right there on my screen. 
User1: Wait, what timezone are you? What's the UTC-time? 
User2: What is UTC? Is that something with computers? 
User1: OMFG! *click* 

Szukam porady na temat przechowywania danych.

Myślę o przechowywaniu wszystkich datetimes w UTC i dodaniu dodatkowej kolumny zawierającej oryginalną nazwę strefy czasowej, w formie, która pozwala mi użyć mysql CONVERT_TZ lub odpowiednika w Javie. Aplikacja będzie następnie konwertować daty wprowadzone przez użytkownika na UTC i mogę łatwo wysłać zapytanie do bazy danych. Wszystkie daty można również łatwo przekonwertować na czas lokalny użytkowników w aplikacji. Korzystając z oryginalnej kolumny strefy czasowej, będę również mógł wyświetlić oryginalną datę i godzinę.

jednak oznacza to, że dla każdego datetime muszę, muszę dodatkową kolumnę ...

start_time_utc datetime 
start_time_tz varchar(64) 
end_time_utc datetime 
end_time_tz varchar(64) 

jestem na dobrej drodze tutaj?

Czy ktokolwiek, kto pracował z takimi danymi, podzielił się swoimi doświadczeniami?

(będę używał MySQL 5.5 CE)

Update 1

Dane zostaną dostarczone w plikach XML, gdzie każdy wpis ma datetime w jakiejś lokalnej strefy czasowej. Tak więc będzie tylko jeden proces wstawiania, działający w jednym miejscu.

Po załadowaniu do bazy danych będzie ona prezentowana w niektórych aplikacjach internetowych użytkownikom w różnych strefach czasowych. W większości przypadków dane będące przedmiotem zainteresowania pochodziły również z tej samej strefy czasowej, co użytkownik przeglądający dane. W przypadku niektórych bardziej skomplikowanych przypadków użycia seria zdarzeń jest połączona i obejmuje wiele stref czasowych. Dlatego użytkownicy chcą mieć możliwość porozmawiania o zdarzeniach w celu zbadania prawdopodobnych przyczyn/konsekwencji w czasach drugiej osoby. Nie UTC, a nie ich czas lokalny.

Answer 1

Instrukcja ma część tylko do tego, o datownika:

wartości TIMESTAMP są konwertowane z aktualnej strefy czasowej UTC do przechowywania i przekształcany z powrotem do UTC do aktualnej strefy czasowej pobieranie. (Ma to miejsce tylko dla typu danych TIMESTAMP o numerze , a nie dla innych typów , takich jak DATETIME.) Domyślnie bieżąca strefa czasowa dla każdego połączenia jest czasem serwera. Strefa czasowa może być ustawiona na dla każdego połączenia, jak opisano w Rozdział 9.6, "Strefa czasowa serwera MySQL Wsparcie". Dopóki strefa czasowa pozostanie niezmieniona, odzyskasz tę samą wartość, którą zapiszesz.Jeśli przechowujesz wartość TIMESTAMP, a następnie zmienisz strefę czasową i pobierzesz wartość, uzyskana wartość różni się od zapisanej wartości . Dzieje się tak, ponieważ ta sama strefa czasowa nie była używana do konwersji w obu kierunkach. Aktualna strefa czasowa jest dostępna jako wartość zmiennej systemowej time_zone .

http://dev.mysql.com/doc/refman/5.5/en/timestamp.html

Więc można użyć: SET time_zone = timezone; na kliencie, aby ustawić strefę czasową. Wtedy wszystkie zapytania przetłumaczyłyby znacznik czasu na prawidłową strefę czasową. Nie musisz robić nic skomplikowanego w Javie, z wyjątkiem ustawiania strefy czasowej (myślę, że może to być nawet parametr w łańcuchu połączenia JDBC).

Answer 2

Zawsze możesz uzyskać czas zulu jako podstawę dla wszystkich swoich obliczeń.

Answer 3

Ponieważ użytkownicy mogą mieszkać w różnych strefach czasowych, a nawet przenieść się z jednej strefy czasowej do drugiej, najlepszą praktyką jest przechowywanie daty i godziny w UTC i przejście do strefy czasowej użytkownika w momencie wyświetlania.