Эгея и часовые пояса
Люди интересовались тем, как в Эгее работают часовые пояса, если я убрал всё про управление ими. Дело в том, что E2 хранит с каждой заметкой не только абсолютное время (timestamp), когда её написали, но и часовой пояс, где это было, чтобы отображаемое в человеческом формате время всегда было правдой. И раньше управление всем этим создавало разные неудобства.
Для начала напомню, как именно было дело раньше. При инсталляции спрашивалось, в каком часовом поясе вы находитесь и используется ли в нём летнее время. Далее этот часовое пояс прописывался как «текущий часовой пояс» и именно он пихался каждой заметке. При смене часового пояса (например, вы поехали в отпуск) необходимо было зайти в настройку и изменить часовой пояс, чтобы в заметках, которые будут написаны из отпуска, прописывался правильный часовой пояс. Ещё можно было зайти в настройку любой заметки и вручную прописать для неё любое время и часовой пояс.
Ясно, что это была жопа, а не система. Необходимость следить за часовым поясом — полная чушь, никто не менял его при переезде, потому что даже не знал, что это есть и как оно на что влияет. Да и лишние поля в инсталляторе никому не грели душу.
Сейчас инсталлятор выглядит так:
Он пытается скриптом определить часовой пояс на компьютере того, кто устанавливает движок. При инсталляции этот пояс прописывается в качестве пояса по умолчанию. Поскольку браузер возвращает лишь разницу с Гринвичем, но не говорит, используется ли в регионе пользователя летнее время, определить это не удаётся, ну и чёрт с ним.
При создании и при публикации заметки часовой пояс тоже определяется скриптом, но если это почему-то не получается, то используется часовой пояс по умолчанию. При этом если дело происходит летом, то заметка, написанная из Москвы, будет сохранена как «GMT+4» вместо правильных «GMT+3 с переходом на летнее время». Но это не беда, так как не оказывает влияния ни на что на свете кроме семантической красоты (которая не оказывает влияния ни на что на свете вообще).
В результате все заметки будут отображаться с правильным временем, а пользователю ничего не нужно будет для этого делать вообще.
Кстати, первые копии уже улетели некоторым из согласившихся потестировать. По мере правки багов буду раздавать всё большему числу людей.
На самом деле данные типа timestamp (time, date, datetime) *всегда* следует хранить с указанием часового пояса. Как вариант — *всегда* по UTC.
Именно поэтому я всегда его и храню, о чём написано в этой заметке.
Прямо захотелось попробовать.
Где искать инвайты? ;)
Пришлю постепенно.
Илья, вот-вот, я и говорю: вы пришли к правильному решению.
Спасибо за развёрнутый ответ!
Мне не совсем понятно про Москву летом и GMT+4. Если заметка была написана в 20:00, то и на сайте она будет отображаться как «написанная в 20:00». Я правильно понимаю?
Если так, то почему это должно беспокоить? Время ведь отображается правильно.
А ведь можно ещё пробовать узнавать город пользователя (по айпи или через геолокацию в браузере) и вычислять время в этом городе.
Мне интересен ещё вот такой момент: допустим в московском аэропорту пишет заметку «вылетаю в Нью-Йорк, всем чмоке». Садится в сверхзвуковой самолёт и через 5 часов он в нью-йоркском аэропорту пишет «удачно долетел». Ведь вторая его заметка отметится с временем более ранним, чем предыдущая. Как поступать? %-)
Время будет отображаться правильно.
Заметка, написанная следующей, будет отображаться следующей, даже если на часах в том регионе, куда вы прелетели, меньшее число.
Это называется «магия» :-)
Илья, а нет желание выложить код на гитхаб? Это было бы очень удобно тем, кто будет искать в нем ошибки и править их, отправляя тебе патчи.
Ошибки в коде править никто кроме меня не будет, он закрытый.
Илья, а зачем вообще спрашивать часовой пояс у браузера? Заметка сохраняется со временем UTC, вычисленным по часам сервера. Читателям отдается страница в таймстемпами UTC и джаваскриптом приводится в часовой пояс читателя. Всё. Все всегда видят время в своем часовом поясе.
Или вы хотите показывать wall clock время написания заметки?
Время писателя, а не читателя важно.
Лучше всего проблему часовых поясов решает время в формате «заметка написана два часа назад». На самом деле, пользователю все равно, написана заметка в 18.00 или в 19.02 — ему гораздо важнее то, насколько давно она написана.
Это верно, когда речь идёт о двух часах назад. А вот «август 2009» куда понятнее, чем «7 месяцев назад».
Даже при том, что браузер возвращает только разницу с Гринвичем, текущий часовой пояс все же возможно определить. Идея такая: создаем объект даты со временем в ключевых точках — в датах, когда возможен переход на летнее или зимнее время. Создаем такой же объект, но в UTC. По разнице видим, произошел ли перевод стрелок, или нет.
Правильно. Что характерно, «Август 2009» тоже не страдает проблемой часовых поясов. Я не стал расписывать, очевидно, что надо будет писать не «22 часа назад», а «вчера», не «8 дней назад», а «неделю назад», «не пять недель назад», а «месяц назад», не «два месяца назад», а «в августе 2009».
Хотите делать для людей — делайте. Главное, правильно подобрать эти промежутки смены формулировки. И часовые пояса тогда никогда не станут помехой.
А зачем пхп-ешный код дизайнера делать не опенсорсным? Продавать что ли? ;) Народ же по ходу действительно использует, никто же не мешает пулл-реквесты противоречищает Дизайн-Идее не принимать.
Определить смещение на летнее время для текущей таймзоны в браузере можно. И весьма элементарно. Через сравнение смещения таймзоны для пары любых зимних и летних дат.
Ясно. Тогда проще всего было бы сохранять wall clock time из браузера, а реальный ютисишный таймстемп брать на сервере. Сортировать по второму, показывать первое. Все операции с часовыми поясами таким образом уходят совсем.
Илья, я совершенно не по теме.
Уже несколько дней пользуюсь селектой, и хочу поблагодарить за механизм черновиков. Это абсолютно офигенная и удобная фича. Ну а <meta robots=«noindex»> — это весело было найти, конечно :)
Вопрос ещё по обязательной строчке «работает на селекте». Можно ли слегка изменить её через str_replace? А то сейчас получается, будто это я работаю на e2, поэтому хочу там написать «Блог работает», для этого нужно str_replace(’Р’, ’р’) сделать.
А бету Эгеи не хотите? Там черновики ещё круче.
А что весёлого в метароботах?
Слегка изменить, конечно, можно.
А расскажите что такого клёвого в черновиках Селекты и Эгеи? :)
Весёлого — что я пару дней не понимал, почему поисковики заходят на сайт, тут же уходят и всё, при этом никаких robots.txt. Ну это несложно было поправить, и уже не актуально.
Про бету Эгеи думал, но там уже желающих отметилось достаточно дофига (плюс пожелание насчёт методов исправления ошибок, чем мне лень заниматься), а у меня лишь мелкий блог, к которому требование только одно — чтобы работал. Ну и поскольку я уже начал, то несколько осторожно отношусь к процессу обновления: мало ли там будут жуткие глюки, и придётся с трудом откатываться, восстанавливать бэкап базы и тому подобное.
Так что я немного подожду, пока хотя бы самые явные ошибки найдут.
Там noindex, follow. Потому что нефиг индексировать главную, которая постоянно меняется, а индексировать надо страницы с конкретными заметками. Какие поисковики от вас уходят — не знаю.
Но вообще да, это можно убрать, конечно.
Виктор, клёвое там то, что можно писать записи впрок и обстоятельно. Например, в своём новостном блоге я решил делать ежедневную утреннюю запись, а это сложно без предварительной подготовки. Поэтому у меня в черновиках лежит несколько заготовок на ближайшие дни (когда нет срочных новостей). Ну и просто иногда новость составляется несколько часов, по мере появления дополнительной информации. Обычно для такого используют либо стороннюю программу (блокнот), либо отложенные записи, но это криво и неудобно.
Илья, но в этом блоге на главной index, follow стоит. Почему?
Лучше meta robots убрать, пусть блогеры сами решают: движок же не придумывает за них, например, meta description. А если в сети нет ссылок на конкретные записи, то поисковики про них, получается, не узнают. По крайней мере, пока стояло noindex, боты яндекса и гугля никуда дальше главной не заходили. Можно явно robots.txt сделать, чтобы неожиданностей не было.
В этом блоге стоит в рамках жадности :-) Потому что «Сапа» даёт размещать ссылки только на индексируемых страницах. Движок пусть всё-таки за пользователя решает всё, что может. Если что, пользователь поправит, а по умолчанию будет так, как я считаю правильным :-)
Илья З.,
Ссылки на конкретные записи очень даже индексируются, т. к. стоит follow, а в самих заметках index.
Хорошо, что должен показать поисковик при запросе «Блог Ильи Бирмана»?
Илья З., в этом соглашусь.
И ещё вопрос: почему в Эгее /everything/ вместо красивой и информативной таблицы, как в Селекте, рисуется бессмысленным списком всего (есть же поиск)? Хотелось бы иметь способ вернуть таблицу.
Отталкивает кодировка win1251. Понятно, что переводить всё в утф8 геморно, но ведь решаемо же!
Я научился расставлять приоритеты.
Чтобы не задавать глупые вопросы, попробуем юникод.
Математикой:
∀x∈ℝ: ⌈x⌉ = −⌊−x⌋, α ∧ ¬β = ¬(¬α ∨ β),
Лингвистикой:
ði ıntəˈnæʃənəl fəˈnɛtık əsoʊsiˈeıʃn
Демосфеном:
Οὐχὶ ταὐτὰ παρίσταταί μοι γιγνώσκειν, ὦ ἄνδρες ᾿Αθηναῖοι,
Грузинским:
გთხოვთ ახლავე გაიაროთ რეგისტრაცია Unicode-ის მეათე საერთაშორისო
Брайлем:
⡌⠁⠧⠑ ⠼⠁⠒ ⡍⠜⠇⠑⠹⠰⠎ ⡣⠕⠌
Всё работает, но Уникода пока не будет.
Денис, ваше правило о совместном хранении timestamp и часового пояса, мягко говоря, странное. Во-первых, в этом нет необходимости, так как timestamp какого-то конкретного момента один и тот же в разных часовых поясах. Во-вторых, в этом нет смысла, если на сайте не один автор, а несколько из разных часовых поясов (например, если это форум).
Роман, так именно поэтому и нужно хранить часовой пояс: чтобы знать, как таймстамп преобразовать в человеческое время.
Тогда часовой пояс должен храниться с другими параметрами пользователя. Просто слова «данные типа timestamp всегда следует хранить с указанием часового пояса» воспринимаются так, что часовой пояс нужно хранить в каждом посте, вместе со временем его написания.
Именно так и нужно делать и так я и делаю. Люди перемещаются между часовыми поясами, не переставая писать заметок.