Pull to refresh

Comments 35

правильнее время определять конечно по IP, но там с мобильными операторами проблема будет.
у многих моих знакомых стоит Московское время, хотя живем мы на 2 часа позже (потому что им так продали и они не знают как время перевести, или переводят, а оно обновляется с интернета опять на GMT+3 :)
Покрытие решения выше шире + решает проблему с пользователями, которые «живут по другому часовому поясу».
Тогда уж надежнее получать время на машине пользователя, сравнивать с серверным, а потом уже определять часовой пояс. Проблема в том, что у многих верное время и при этом неверный пояс.
Когда мы то же самое придумали, обходились без Ajax, одними кукисами. С отключенными кукисами сайт всё равно бы не работал (аутентификация) и специфика веб-приложения позволяла гарантировать, что при первой загрузке даты показывать не надо.

Ещё можно обернуть все даты в специальный блок, скажем, <span class=«datetime» data-time=«1282756067»>2010-08-26 00:07:47</span>, а JS-функция их все разом сконвертит в локальное время.
Можно использовать HTML5 тег: <time datetime=«1282756067»>2010-08-26 00:07:47</time>.
offtopic: а почему у вас идентификаторы называются please_*?
Давайте лучше сделаем что-нибудь вроде woul_you_be_so_kind_to_set_time_zone?
Или sorry_to_trouble_you_but_could_you_parse_this?
У меня у клиента и сервера очень хорошие отношения. Поэтому они обращаются друг к другу вежливо. :)
Смущает вот этот кусок:

offset = timedelta(hours=int(timezone_offset))

Насколько я помню, где-то в арабских странах смещение может дробным, типа 3,5 часа
вообще, конечно, правильно написал Hint #:
у очень многих юзеров стоит правильное время, но неправильная таймзона. из-за этого бывают баги с короткоживущими куками.
Чтобы не было таких проблем, RFC 2965 назначает кукам свойство Max-Age, и ни словом не говорит про свойство Expires — тяжкое наследие Нетскейпа.

Только мало кто ещё его пользует.
UFO just landed and posted this here
Какая разница сколько — лучше перебдеть, чем недобдеть.
Лично я каждую неделю читаю тамошних журналистов. Так что есть, есть.
UFO just landed and posted this here
Что-то решение бадяжное) не учитывает переход на летнее время… ведь не все страны переводят часы, соответственно часовых поясов становится больше… Лучшего решения, описанного Джошем Фразером — www.onlineaspect.com/2007/06/08/auto-detect-a-time-zone-with-javascript/, пока не встречал)…
О чём Вы?

Речь не идёт о запоминании времени в базе данных в, скажем, таблице пользователей. Оно сохраняется в сессии. Потом сессия заканчивается, и время считывается ещё раз.
Кто вообще говорил про базу данных? Речь о Вашем определении часовой зоны с помощью функции getTimezoneOffset(). Где хотите, там и запоминайте часовой пояс — в базе, сессии, куках — ваше право.

Топик называется «Автоматическое определение часового пояса пользователя», которое свилось с вызову данной фукнции, которая не совсем-то точно работает ;) По моей ссылке вы сможете найти работающий кроссбраузерный алгоритм определения часовой зоны пользователя.
Тогда да, об этом я был не в курсе. Но тут смысл больше в общей схеме взаимодействия, а не этой конкретной строчке. Как уже писали выше, довольно эффективным может быть сравнение локального времени пользователя с временем UTC на сервере. Я об этом тоже думал, но в статью добавил более простой в реализации вариант. Предполагается, что уже готовое решение улучшать проще. :)

Спасибо за информацию, Павел.
Я делаю еще проще.
Все даты у меня возвращаются пользователю, как Unixtime в UTC. После, скармливаю этот таймштамп объекту Date: new Date(), а Javascript знает, что Unixtime должен быть в UTC и сам корректирует дату с учетом текущего часового пояса пользователя. И в конце можно отформатировать дату как угодно, перед отображением пользователю. Таким образом, я никогда у пользователя не спрашиваю его часовой пояс, но даты ему отображаются корректно.
Особенно приятно, что этот самый timestamp легко достается из ObjectID MongoDB.
из ObjectID доставал, но оборачивать в new Data() и получать локальное время не додумывался, премного благодарен!
Да, все гениальное — просто. Почему этот подход не получил распространения, мне не понятно.
Получил. Просто все в Москве готовятся к предстоящему велопробегу ;-)
Создадим новый Django-проект.

Внезапно.
Всё, что уходит на сервер, должно быть в GMT, а на клиенте можно показывать в его временной зоне. Как правило, это решает все проблемы.
Для справки: в Петропавловске-Камчатском теперь UTC+11 (летом UTC+12), поэтому теперь в полночь по московскому времени там было бы 8 часов, а не 9.
Спасибо нашей партии, поклон ей до земли!!!
© Сектор Газа.

ЗЫ Из-за этого идиотизма столько проблем блин…
и вобще — нехуй было землю круглой делать. оставили бы плоской, как раньше.
Статью можно было урезать до html-кода и кода функций, если она не ставит своей целью научить создавать джанго-проекты.
А зачем? Те, кто знают, что делать, просто пропустят кусок, а те, кто не знают, могут научиться. :)

В своём недавнем скринкасте (Programming an image hosting application with Django, час Django-видео в 1920x1080), например, проект тоже создаётся с нуля. Мне вообще кажется, что постепенное продвижение вперёд — очень уютный, медитативный процесс. :)
Конечно, толпа сейчас рванула изучать джанго дабы автоматически определять часовой пояс пользователя.

>час Django-видео в 1920x1080
Рекомендую озвучивать их на Django-русском или серьезно поработать над произношением Django-английского. Ради Django-добра.
ага.
а кто не знает джанго — пусть разберуться в джанге, поймут логику работы, и уже потом переделают по свой фреймворк.
А ещё есть сайты, где пользователи в своём профиле сами указывают регион/город своего нахождения (типа Хабра). И там вообще можно было бы показывать юзерам время постов/комментариев в их локальном времени, ведь привязка часовых поясов к регионам известна. Но почему-то Хабр этого не делает.
Часовой пояс != смещению от Гринвича.
Sign up to leave a comment.

Articles