Moja witryna ma regularnie zaplanowane przez użytkownika wydarzenia. Obecnie używamy naszej strefy czasowej EDT (lub EST) jako podstawowej strefy czasowej dla wszystkich zdarzeń w witrynie. Wydaje mi się, że jest to albo 1) zły, albo 2) bardzo mylący. Obecnie mamy użytkowników w całych Stanach Zjednoczonych i Europie.
Czy właściwa metoda lokalizowania czasu oparta jest na strefie czasowej klienta? używać UTC / GMT?
Dzięki
Szczerze mówiąc, jest to jeden problem, który często pojawia się, gdy strona internetowa jest używana w wielu strefach czasowych. Istnieje długa lista sposobów na pokonanie bitwy. Podsumowując badp, istnieje wiele czynników, które wpływają na sposób przetwarzania różnych stref czasowych.
Większość stron internetowych wybiera jedno z dwóch różnych rozwiązań tego problemu:
1) Przechowuj w bazie danych wszystko, co wiąże się z datą UTC ... i pozwól użytkownikom w Twojej witrynie wybrać ustawienie strefy czasowej, w której się znajdują ... lub wykonaj magiczne wyszukiwanie geograficzne, aby się dowiedzieć gdzie są na świecie i znajdują odpowiednią strefę czasową ... a następnie za każdym razem, gdy wyświetlasz datę ... pamiętaj, aby wywołać dowolną funkcję potrzebną do lokalizacji. Prawie każdy język programowania ma pewną metodę wyświetlania dat przy użyciu określonej strefy czasowej. W przypadku użytkowników wstawiających daty musisz to zrobić odwrotnie. (weź czas lokalny i przekonwertuj z powrotem na UTC w celu przechowywania DB) Jest to prawdopodobnie najbardziej popularne podejście. Pozwoliłoby to również zaoszczędzić dużo czasu od próby „ponownego wynalezienia koła”. Jeśli chodzi o anonimowych odwiedzających ... możesz albo A) trzymać się EST / EDT (używając wbudowanych wywołań funkcji do wyświetlania odpowiednio), albo B) powrócić do Geo-IP-Lookup i wybrać strefę czasową opartą na wyuczonym zgadywaniu. Dobrym pomysłem jest również zawsze określanie strefy czasowej, w której wyświetlana jest data / godzina. Tzn. Nigdy nie mów „12:00” ... upewnij się, że jest to „12:00 EDT”
lub 2) Postępuj zgodnie z modelem stosu wymiany (i wieloma innymi), pokazując różnicę między teraz a momentem utworzenia posta. tzn. zamiast „opublikowano w dniu x” ... zrobiłbyś „x godziny temu” lub „x dni x godziny temu” itd.… lub dla przyszłych dat… ”za 6 dni 14 godzin ...” To szybko staje się bardziej powszechny w wielu sytuacjach ... ale nie jest tak idealny do harmonogramów typu kalendarza.
Oczywiście ... nadal możesz zastosować pewnego rodzaju hybrydę dwóch ... i może być konieczne pójście o krok dalej i zapisanie dat jako utc ... ale także zapisanie określonej strefy czasowej dla wydarzenia. Ostatecznie decyzja należy do ciebie.
Oto problem: UE i USA nie włączają i wyłączają DST w tym samym czasie; w marcu między tymi wydarzeniami były trzy tygodnie różnicy.
Oto, co dzieje się w tym okresie. Załóżmy, że masz wydarzenie każdego dnia o tej samej porze, a ponieważ mieszkasz w USA, dostosujesz czasy za pomocą US DST.
Day (2001) United States Europe United Kingdom Global Time delta
March 5th EST 1500 CET 2100 GMT 2000 GMT 2000 +23h
March 6th EDT 1500 CET 2000 GMT 1900 GMT 1900 +24h
March 7th EDT 1500 CET 2000 GMT 1900 GMT 1900 +24h
..............................................................................
March 26th EDT 1500 CET 2000 GMT 1900 GMT 1900 +24h
March 27th EDT 1500 CEST 2100 BST 2000 GMT 1900 +24h
Przeanalizujmy wszystkie możliwości:
Jeśli wyświetlasz czas w globalnej strefie czasowej i nazywasz go UTC , co wydaje się słuszne, będziesz mylić swoich amerykańskich klientów, którzy zobaczą różne godziny UTC (wczoraj 20:00, dziś 19:00) dla ten sam zegar ścienny (wczoraj godzina piętnasta, dziś znowu godzina piętnasta), a następnie klienci z UE, którzy nie widzą zmian w opublikowanym zegarze czasowym, a mimo to muszą zmienić czas zdarzenia zegara ściennego.
Jeśli wyświetlasz czas w globalnej strefie czasowej i nazywasz go GMT , oprócz mylących klientów w Stanach Zjednoczonych będziesz także mylić klientów w Wielkiej Brytanii, którzy przechodzą z GMT na BST. Jest sprzeczne z intuicją rozumieć, że EDT 1500 i EST 1400 są w tym samym momencie; teraz przetłumacz to na BST / GMT (z dodatkowym problemem, że nie będziesz pokazywał czasów BST w żadnej części witryny).
Jeśli wyświetlasz strefę czasową w strefie czasowej UE (użyłem CET / CEST, aby uniknąć pomyłek GMT / UTC), to oczywiście będzie bardzo mylące dla klientów w USA, którzy widzą, że czas wydarzenia zmienia się tam iz powrotem dwa razy, a mimo to nie doświadczają żadnej ściany zegar zmienia się sam. Podczas gdy Twoi klienci w USA mogą być przygotowani na pierwszą zmianę (w końcu muszą zmienić swoje zegary ścienne tego samego dnia), będą zaskoczeni tym drugim.
Jeśli wyświetlisz strefę czasową w strefie czasowej w USA (np. EST / EDT ), dokładna sytuacja zostanie wyjaśniona powyżej, ale zostanie dublowana!
To wygląda na beznadziejną sytuację! Oto, w jaki sposób zająłem się tym po czterech latach omawiania tej zasady (oczywiście dwa razy w roku): „stwórz strefę czasową”.
Jestem dokładnie w takiej sytuacji, jak na powyższej ilustracji, więc wymyśliłem „NYT” (strefa czasowa w Nowym Jorku), abym mógł napisać „1500 NYT”, co oznacza „godzina piętnasta w dowolnej strefie czasowej, z której korzysta Nowy Jork”.
Ma to tę zaletę, że dopóki użytkownik wie, że waltzer DST ma miejsce, ma bardzo prosty sposób na konwersję do własnej strefy czasowej: Google „ czas w Nowym Jorku ”, aby zobaczyć, która jest godzina w Nowym Jorku , a następnie opracujcie to stamtąd. Możesz nawet uzyskać upodobanie i korzystać z usług opartych na geolokalizacji, takich jak time.is/15:00_in_New_York .
Należy zauważyć, że podczas gdy mogłaby używać strefy czasowej nazwy Skrót w Time.is, wzywam was nie, bo są dość mylić o tym wszystkim się: EST ma taki sam czas jak EDT ‽
Możesz powiadomić użytkowników o DST z krótkim napisem, łącząc się z odpowiednią usługą konwersji czasu, aby pomóc ludziom. Idealnie wszystkie znaczniki czasu powinny mieć opcję konwersji na czas lokalny.
Kiedy wszystko zostanie już powiedziane i zrobione, powinieneś zdać sobie sprawę, że przez cały czas ignorowałem słonia w pokoju, a to rozwiązanie, które już wdrożyłeś. Nie ma nic mylącego w „za 1 dzień 2 godziny 45 minut 47 sekund” (a jeśli uważasz, że nie potrzebujesz tak dużej precyzji, możesz pomyśleć jeszcze raz ).
Jasne, z mojego doświadczenia nigdy nie miałem luksusu, który nie byłby statycznym tekstem, więc musiałem poradzić sobie z niesamowitym bałaganem przedstawionym powyżej (i to dopiero początek ! A co z południową półkulą, która odwraca DST?) , ale w twoim przypadku wygląda to na rozwiązanie o najmniejszym potencjale nieporozumień. Możesz dostać dwa wątki rocznie pytające o zdarzenia „za 23 godziny” i „za 25 godzin”, podczas gdy zwykle odlicza się od „za 24 godziny”, ale to wszystko.