Comments 35
правильнее время определять конечно по IP, но там с мобильными операторами проблема будет.
у многих моих знакомых стоит Московское время, хотя живем мы на 2 часа позже (потому что им так продали и они не знают как время перевести, или переводят, а оно обновляется с интернета опять на GMT+3 :)
у многих моих знакомых стоит Московское время, хотя живем мы на 2 часа позже (потому что им так продали и они не знают как время перевести, или переводят, а оно обновляется с интернета опять на GMT+3 :)
-11
Тогда уж надежнее получать время на машине пользователя, сравнивать с серверным, а потом уже определять часовой пояс. Проблема в том, что у многих верное время и при этом неверный пояс.
+5
Когда мы то же самое придумали, обходились без Ajax, одними кукисами. С отключенными кукисами сайт всё равно бы не работал (аутентификация) и специфика веб-приложения позволяла гарантировать, что при первой загрузке даты показывать не надо.
Ещё можно обернуть все даты в специальный блок, скажем, <span class=«datetime» data-time=«1282756067»>2010-08-26 00:07:47</span>, а JS-функция их все разом сконвертит в локальное время.
Ещё можно обернуть все даты в специальный блок, скажем, <span class=«datetime» data-time=«1282756067»>2010-08-26 00:07:47</span>, а JS-функция их все разом сконвертит в локальное время.
+2
offtopic: а почему у вас идентификаторы называются please_*?
Давайте лучше сделаем что-нибудь вроде woul_you_be_so_kind_to_set_time_zone?
Или sorry_to_trouble_you_but_could_you_parse_this?
Давайте лучше сделаем что-нибудь вроде woul_you_be_so_kind_to_set_time_zone?
Или sorry_to_trouble_you_but_could_you_parse_this?
+19
У меня у клиента и сервера очень хорошие отношения. Поэтому они обращаются друг к другу вежливо. :)
+6
Может, автор привык писать на INTERCAL? :)
+1
Смущает вот этот кусок:
offset = timedelta(hours=int(timezone_offset))
Насколько я помню, где-то в арабских странах смещение может дробным, типа 3,5 часа
offset = timedelta(hours=int(timezone_offset))
Насколько я помню, где-то в арабских странах смещение может дробным, типа 3,5 часа
+1
А в Катманду и вовсе UTC+5:45
0
UFO just landed and posted this here
Что-то решение бадяжное) не учитывает переход на летнее время… ведь не все страны переводят часы, соответственно часовых поясов становится больше… Лучшего решения, описанного Джошем Фразером — www.onlineaspect.com/2007/06/08/auto-detect-a-time-zone-with-javascript/, пока не встречал)…
0
О чём Вы?
Речь не идёт о запоминании времени в базе данных в, скажем, таблице пользователей. Оно сохраняется в сессии. Потом сессия заканчивается, и время считывается ещё раз.
Речь не идёт о запоминании времени в базе данных в, скажем, таблице пользователей. Оно сохраняется в сессии. Потом сессия заканчивается, и время считывается ещё раз.
0
Кто вообще говорил про базу данных? Речь о Вашем определении часовой зоны с помощью функции getTimezoneOffset(). Где хотите, там и запоминайте часовой пояс — в базе, сессии, куках — ваше право.
Топик называется «Автоматическое определение часового пояса пользователя», которое свилось с вызову данной фукнции, которая не совсем-то точно работает ;) По моей ссылке вы сможете найти работающий кроссбраузерный алгоритм определения часовой зоны пользователя.
Топик называется «Автоматическое определение часового пояса пользователя», которое свилось с вызову данной фукнции, которая не совсем-то точно работает ;) По моей ссылке вы сможете найти работающий кроссбраузерный алгоритм определения часовой зоны пользователя.
+1
Тогда да, об этом я был не в курсе. Но тут смысл больше в общей схеме взаимодействия, а не этой конкретной строчке. Как уже писали выше, довольно эффективным может быть сравнение локального времени пользователя с временем UTC на сервере. Я об этом тоже думал, но в статью добавил более простой в реализации вариант. Предполагается, что уже готовое решение улучшать проще. :)
Спасибо за информацию, Павел.
Спасибо за информацию, Павел.
0
Я делаю еще проще.
Все даты у меня возвращаются пользователю, как Unixtime в UTC. После, скармливаю этот таймштамп объекту Date: new Date(), а Javascript знает, что Unixtime должен быть в UTC и сам корректирует дату с учетом текущего часового пояса пользователя. И в конце можно отформатировать дату как угодно, перед отображением пользователю. Таким образом, я никогда у пользователя не спрашиваю его часовой пояс, но даты ему отображаются корректно.
Особенно приятно, что этот самый timestamp легко достается из ObjectID MongoDB.
Все даты у меня возвращаются пользователю, как Unixtime в UTC. После, скармливаю этот таймштамп объекту Date: new Date(), а Javascript знает, что Unixtime должен быть в UTC и сам корректирует дату с учетом текущего часового пояса пользователя. И в конце можно отформатировать дату как угодно, перед отображением пользователю. Таким образом, я никогда у пользователя не спрашиваю его часовой пояс, но даты ему отображаются корректно.
Особенно приятно, что этот самый timestamp легко достается из ObjectID MongoDB.
+3
Создадим новый Django-проект.
Внезапно.
+9
Всё, что уходит на сервер, должно быть в GMT, а на клиенте можно показывать в его временной зоне. Как правило, это решает все проблемы.
0
Для справки: в Петропавловске-Камчатском теперь UTC+11 (летом UTC+12), поэтому теперь в полночь по московскому времени там было бы 8 часов, а не 9.Спасибо нашей партии, поклон ей до земли!!!
© Сектор Газа.
ЗЫ Из-за этого идиотизма столько проблем блин…
-1
Статью можно было урезать до html-кода и кода функций, если она не ставит своей целью научить создавать джанго-проекты.
+4
А зачем? Те, кто знают, что делать, просто пропустят кусок, а те, кто не знают, могут научиться. :)
В своём недавнем скринкасте (Programming an image hosting application with Django, час Django-видео в 1920x1080), например, проект тоже создаётся с нуля. Мне вообще кажется, что постепенное продвижение вперёд — очень уютный, медитативный процесс. :)
В своём недавнем скринкасте (Programming an image hosting application with Django, час Django-видео в 1920x1080), например, проект тоже создаётся с нуля. Мне вообще кажется, что постепенное продвижение вперёд — очень уютный, медитативный процесс. :)
0
Конечно, толпа сейчас рванула изучать джанго дабы автоматически определять часовой пояс пользователя.
>час Django-видео в 1920x1080
Рекомендую озвучивать их на Django-русском или серьезно поработать над произношением Django-английского. Ради Django-добра.
>час Django-видео в 1920x1080
Рекомендую озвучивать их на Django-русском или серьезно поработать над произношением Django-английского. Ради Django-добра.
0
ага.
а кто не знает джанго — пусть разберуться в джанге, поймут логику работы, и уже потом переделают по свой фреймворк.
а кто не знает джанго — пусть разберуться в джанге, поймут логику работы, и уже потом переделают по свой фреймворк.
0
А ещё есть сайты, где пользователи в своём профиле сами указывают регион/город своего нахождения (типа Хабра). И там вообще можно было бы показывать юзерам время постов/комментариев в их локальном времени, ведь привязка часовых поясов к регионам известна. Но почему-то Хабр этого не делает.
+1
Часовой пояс != смещению от Гринвича.
0
Sign up to leave a comment.
Автоматическое определение часового пояса пользователя