На моем сайте регулярно проходят запланированные пользователем мероприятия. Прямо сейчас мы используем наш часовой пояс EDT (или EST) в качестве базового часового пояса для всех событий на сайте. Я чувствую, что это либо 1) неправильно, либо 2) очень запутанно. В настоящее время у нас есть пользователи по всей территории США и Европы.
Является ли правильный метод для локализации времени на основе часового пояса клиентов? использовать UTC / GMT?
Спасибо
Честно говоря, это одна из проблем, которая часто наблюдается при использовании веб-сайта в нескольких часовых поясах. Существует длинный список способов преодоления битвы. Подводя итог badp, есть много факторов, влияющих на то, как обрабатываются разные часовые пояса.
Большинство веб-сайтов выбирают одно из двух разных решений для решения этой проблемы:
1) Сохраняйте в базе данных все, что связано с датой в формате UTC ... и разрешите пользователям на вашем веб-сайте настраивать пользовательские настройки, чтобы выбирать, в каком часовом поясе они находятся ... или выполнить некоторую магию поиска по географическому принципу, чтобы выяснить это. где в мире они находятся и находят соответствующий часовой пояс ... и затем каждый раз, когда вы отображаете дату ... обязательно вызывайте любую функцию, необходимую для локализации. Почти у каждого языка программирования есть какой-то метод для отображения дат, используя указанный часовой пояс. Вы также должны сделать это в обратном порядке для пользователей, вставляющих даты. (взять местное время и преобразовать обратно в UTC для хранения БД) Это, пожалуй, самый распространенный подход. Это также сэкономит вам много времени от попыток «заново изобрести колесо». Что касается анонимных посетителей ... Вы можете либо A) придерживаться EST / EDT (используя вызовы встроенных функций для отображения в зависимости от ситуации), либо B) вернуться к функции Geo-IP-Lookup и выбрать часовой пояс на основе образованного предположения. Это также хорошая идея, чтобы всегда указывать часовой пояс, в котором вы отображаете дату / время. Т.е. никогда не говорите «12:00» ... убедитесь, что он говорит «12:00 EDT»
или 2) Следуйте модели stackexchange (и многим другим) отображения разницы между сейчас и моментом создания поста. то есть вместо «опубликовано в х дате» ... вы бы сделали «х часов назад» или «х дней х часов назад» и т. д. ... или для будущих дат ... "через 6 дней 14 часов ..." Это быстро становится все более распространенным во многих ситуациях ... но не так идеален для расписаний календарного типа.
Конечно ... вы все еще можете принять какой-то гибрид этих двух ... и вам, возможно, придется пойти еще дальше и сохранить даты как utc ... но также сохранить определенный часовой пояс для события. В конечном счете, решение остается за вами.
Вот проблема: ЕС и США не включают и не выключают DST одновременно; В марте этого года между этими событиями была разница в три недели.
Вот что происходит в этот период. Допустим, у вас есть событие каждый день в одно и то же время, и, поскольку вы находитесь в США, вы будете корректировать время, используя 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
Давайте проанализируем все возможности:
Если вы отображаете время в глобальном часовом поясе и называете его UTC , что кажется правильным, вы запутаете своих американских клиентов, которые увидят разное время UTC (вчера 20:00, сегодня 19:00) для то же самое время настенных часов (вчера в 15:00, сегодня снова в 15:00), а затем ваши клиенты из ЕС, которые не видят изменения в опубликованных часах и все же должны изменить свое время настенных часов.
Если вы отображаете время в глобальном часовом поясе и называете его GMT , в дополнение к тому, что вы сбиваете с толку клиентов из США, вы также вводите в заблуждение клиентов из Великобритании, которые переключаются с GMT на BST. Противоречиво понимать, что EDT 1500 и EST 1400 - это один и тот же момент времени; теперь переведите это в BST / GMT (с дополнительной проблемой, что вы не собираетесь показывать время BST в какой-либо части сайта).
Если вы отображаете часовой пояс в часовом поясе ЕС (я использовал CET / CEST, чтобы избежать путаницы по Гринвичу / UTC), это, очевидно, будет очень запутанно для ваших клиентов из США, которые видят, что время события переключается назад и вперед дважды, и при этом не имеют стены. Часы меняются сами по себе. В то время как ваши американские клиенты могут быть готовы к первому переключению (после того, как им придется менять настенные часы в тот же день), они будут удивлены последним.
Если вы отобразите часовой пояс в часовом поясе США (например, EST / EDT ), вы получите точную ситуацию, описанную выше, но зеркальную!
Это похоже на безнадежную ситуацию! Вот как я пришел к решению этой проблемы после четырех лет прохождения этого рингмола (очевидно, два раза в год): «создать часовой пояс».
Я нахожусь точно в ситуации, изображенной выше, поэтому я составил «NYT» (часовой пояс Нью-Йорка), чтобы написать «1500 NYT», что означает «3 часа дня в любом часовом поясе, который использует Нью-Йорк».
Это имеет то преимущество, что, пока пользователь знает, что происходит вальсинг DST, у него есть очень простой способ конвертировать туда и обратно в их собственный часовой пояс: Google « время в Нью-Йорке », чтобы увидеть, сколько времени в Нью-Йорке , тогда решите это оттуда. Вы даже можете стать модным и использовать службы на основе геолокации, такие как time.is/15:00_in_New_York .
Обратите внимание, что, хотя вы можете использовать имена сокращений часовых поясов в time.is, я призываю вас не делать этого, поскольку они сами довольно запутались: EST имеет то же время, что и EDT T
Вы можете уведомить пользователей о летнем времени с некоторой краткой рекламой, связавшись с соответствующим веб-сервисом преобразования времени, чтобы помочь людям. В идеале все метки времени должны иметь возможность преобразования в местное время.
Когда все сказано и сделано, вы должны понимать, что я все время игнорирую слона в комнате, и это решение «обратного отсчета», которое вы уже внедрили. Нет ничего странного в том, что «за 1 день 2 часа 45 минут 47 секунд» (и если вы считаете, что вам не нужна такая большая точность, вы можете подумать еще раз ).
Конечно, по моему опыту, у меня никогда не было такой роскоши, как не статичный текст, поэтому мне пришлось справиться с невероятным беспорядком, изображенным выше (и это только начало ! Как насчет южной полушарии, которая делает DST задом наперед?) , но для вашего варианта использования это звучит как решение с наименьшей вероятностью путаницы. Вы можете получать два потока в год, спрашивая о событиях «через 23 часа» и «через 25 часов», в то время как обычно он ведет обратный отсчет от «через 24 часа», но это все.