Часовые пояса

[codedokode]

Сейчас 2ch не работает, так что придется поверить на слово, но на открытой у меня странице тред 101 создан в 04:26:35, а на phpclub.tech у этого же треда время создания указано 02:26:35. Похоже. что то ли там баг, то ли это не московское время. Или, как вариант, сам двач криво отображает время в JSON-выгрузке. Можно будет это проверить, когда сайт поднимут. Если это не баг, то, мне кажется, логично тогда указать часовой пояс (это наверно в любом случае имеет смысл, так как люди живут в разных регионах и у них может быть разное местное время).

[someApprentice]

У меня не получается проверить какой часовой пояс создается в ответе JSON, т.к. почему-то постинг на 2ch не работает.

В любом случае, можно вывести время в соответствии с часовым поясом программно. Лучшим вариантом я вижу воспользоваться расширением GeoIP, чтобы получить временную зону в соответствии с ip и вывести само время.

https://secure.php.net/manual/ru/book.geoip.php
https://secure.php.net/manual/ru/function.geoip-region-by-name.php
https://secure.php.net/manual/ru/function.geoip-time-zone-by-country-and-region.php

[codedokode]

Запостил пост https://2ch.hk/pr/res/1174695.html#1178654 примерно в 9:57 по Московскому времени (6:57 UTC). Отображается на 2ch как 10:57 (возможно из-за моих настроек ОС). В JSON идет как "date":"24/04/18 Втр 09:57:07", "timestamp":1524553027. Если расшифровать таймстамп, получается Tue, 24 Apr 2018 10:57:07 +0400 или те же самые 6:57 UTC.

Как я понимаю, 2ch хранит время верно, а выводит с отступом +4 от UTC, это Московское время, но сбитое на час, скорее всего из-за устаревшей базы таймзон (в последние годы у нас пару раз меняли график летнего времени). По крайней мере с моего компьютера.

Насчет GeoIp - там есть подвохи. Необходимо скачать и периодически обновлять базу, плюс, бывают случаи, когда человек пользуется мобильной связью в одном регионе, а в интернет пакеты идут из другого. Также, бывают случаи, когда люди сидят через прокси или VPN - им будет показываться не та зона. Бывают неточности в базе. Но в общем, сама идея мне нравится - показывать местное время, только желательно тогда указывать название часового пояса.

Есть еще другой вариант. В браузере можно определить часовой пояс ОС с помощью Яваскрипта: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/getTimezoneOffset

console.log((new Date()).getTimezoneOffset()/60);

У меня это выводит -4, например (не знаю, почему так).

Но подвох тут в том, что это делается с помощью Яваскрипта, и на момент первого запроса значение неизвестно. Как компромисс, можно использовать такой алгоритм:

• если в запросе передана кука с часовым поясом, берем ее
• если куки нет, отдаем время в UTC или какой-то другой дефолтной зоне и запускаем скрипт определения пояса и кладем результат в куку
• как вариант, дефолтное значение можно брать из GeoIP

Единственное, что беспокоит, не слишком ли сложно выходит. Плюс, непонятно, на какой срок ставить куку, чтобы учесть переход на летнее время.

[someApprentice]

Есть еще другой вариант. В браузере можно определить часовой пояс ОС с помощью Яваскрипта: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/getTimezoneOffset

console.log((new Date()).getTimezoneOffset()/60);

У меня это выводит -4, например (не знаю, почему так).

Я тоже прежде чем обратиться к GeoIP рассматривал вариант с Яваскриптом но столкнулся с теми же проблемами что и вы:

1. getTimezoneOffset() выдает не то что нужно. Точнее я так думал, потому что в php DateTimezone принимает смещение в часах а не в минутах (new DateTimeZone('+300'))->getName(); // +03:00.

   Соответственно, лучшим решением будет сохранить в куку уже отформатированное для php смещение во времени:

   function getTimezone() {
     var timezone = (new Date()).getTimezoneOffset() / (-0.6);
   
     if (timezone >= 0) {
       timezone = "+" + timezone;
     }
   
     return timezone;
   }
   

   Чтобы ничего не считать, альтернативой может быть Intl.DateTimeFormat().resolvedOptions().timeZone; // Europe/Moscow, но он поддерживается только начиная с 11-ой версии IE.

2. на момент первого запроса значение неизвестно

   (Решение этого подвоха вы уже написали)

Единственное, что беспокоит, не слишком ли сложно выходит.

Это сложно настолько, насколько сложен вопрос смещения во времени. Для его решения потребовались собрать международную конференцию, в которой участвовали лучшие умы от каждого государства. Нам лишь остается пожнать эти знания, и взмахом кода решить эту проблему за секунду.

Плюс, непонятно, на какой срок ставить куку, чтобы учесть переход на летнее время.

Можно поставить на месяц или на неделю, или можно ещё написать скрипт, который сравнивает дату/смещение, и если они отличаются, то пересоздает куку.

[kubk]

Привязка к IP - плохая идея, сейчас всё больше людей в РФ будут пользоваться VPN-ами в свете последних блокировок (у архива ведь основная аудитория не бабушки, а действующие/будущие разработчики, которые уже сейчас вынуждены искать обходные пути для получения информации).

Больше всего раздражает, когда меняют язык сайта против моего желания на основе IP.

[foobar1643]

Немного некропостинг, но как вариант - предлагаю сделать эту опцию настраиваемой, как на 2ch.
Такой подход гибкий, так можно к примеру при первом заходе на сайт ставить всем дефолтную таймзону, а уже на странице через JS проверять соответствует ли дефолтная таймзона той, которая у пользвателя на устройстве. Если не соответствует - можно показывать какой-нибудь ненавязчивый элемент с предложением сменить таймзону на любую желаемую. Ну и сделать возможность менять это без подсказки, на случай если с помощью JS неправильно определилась таймзона.

[codedokode]

Дополню тему подробностями реализации дат/времен в коде. Объект DateTime в PHP представляет абсолютное значение времени и хранит как дату/время, так и таймзону, к которой они относятся. Без таймзоны, очевидно, нельзя сказать, о каком моменте времени идет речь, так как в разных областях планеты оно разное. Если мы не указываем таймзону явно, то она берется из ini-настройки сервера date.timezone (также, ее можно задать функцией date_default_timezone_set()).

Ранее в коде нигде таймзона не указывалась, и дата/время создавались в таймзоне сервера. Я в рамках #42 поменял это, сделав так, что таймзона выбирается в зависимости от сайта, который мы парсим (для 2ch, m2-ch, arhivach это Europe/Moscow) и создается объект DateTime в данной таймзоне.

После парсинга дата/время поста сохраняются в БД. В типе DATETIME таймзона в БД не сохраняется, и Доктрина конвертирует дату/время в локальную таймзону сервера и сохраняет получившееся время. При загрузке из БД происходит обратный процесс, Доктрина берет дату/время из БД и приписывает к ней таймзону сервера. Таким образом, дата/время в БД могут не совпадать с датой/временем в треде если таймзона сервера отличается от используемой на сайте-источнике.

Наконец, при выводе, как я понимаю, никаких преобразований не делается и выводится получившееся время, опять же в таймзоне сервера.

Если на сервере стоит например Europe/London, то время поста в БД и на сайте будет выводиться на 3 часа меньше, чем было на сайте (то есть, выводится местное лондонское время поста).

Такие дела.

Статья по теме про сохранение таймзон в Доктрине: https://www.doctrine-project.org/projects/doctrine-orm/en/2.4/cookbook/working-with-datetime.html