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.Jak przechowywać datetimes w UTC i lokalnej strefie czasowej
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.
Pod względem problemu uważam, że twoje rozwiązanie jest dobre. –
Czy MySQL nie ma "DateTimeOffset", podobnie jak MSSQL (typ danych określający znacznik czasu i jego offset od UTC)? Jeśli tak nie jest, twoje rozwiązanie jest najbliższym odpowiednikiem, różniącym się tylko ilością wymaganych pól (1 vs 2). – bzlm
Nie, MySQL nie obsługuje 'TIMESTAMP WITH TIMEZONE' (który jest typem danych ANSI dla tego) –