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