Javascript / PHP и часовые пояса

Question

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

http://www.michaelapproved.com/articles/daylight-saving-time-dst-detect/

Так что это дает мне смещение вместе с индикатором DST.

Теперь я хочу использовать их в моих сценариях PHP, чтобы вывести локальную дату / время для пользователя .... но что лучше для этого? Я полагаю, у меня есть 2 варианта:

a) Выберите случайный часовой пояс с таким же смещением и настройкой летнего времени из выходных данных timezone_abbreviations_list (). Затем вызовите функцию date_timezone_set () с этим, чтобы применить правильную обработку ко времени.

b) Продолжайте рассматривать дату как UTC, но просто добавьте метку времени, чтобы добавить соответствующее количество часов.

Мне кажется, вариант Б - лучший способ. Причина этого заключается в том, что с A я мог бы использовать часовой пояс, который, хотя и корректен с точки зрения offset / dst, может иметь некоторые неясные правила позади сцены, которые могли бы дать удивительные результаты (я не знаю ни одного, но тем не менее Я не думаю, что могу это исключить).

Затем я бы перепроверил часовой пояс, используя Javascript в начале каждого сеанса, чтобы получить информацию, когда либо часовой пояс пользователя изменяется (очень маловероятно), либо они переходят в период летнего времени.

Извините за потерю мозгов - я действительно только после некоторого заверения, что подходы выше действительны.

Спасибо

Джеймс.

Answer 1

Чтобы надежно определить часовой пояс пользователя с помощью JavaScript. Проверьте jsTimezoneDetect .

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

Answer 2

Если это опрос, то "b" - мой голос.

Во-первых, все время должно храниться в UTC. Это догма. Это очень разумная догма, о которой вы в конечном итоге говорите: «Я бы очень хотел, чтобы я следовал этому», после того как ваш проект усложнился. Среди прочего, это единственный недвусмысленный, последовательный способ хранить все точки во времени. Любой часовой пояс с переходом на летнее время имеет неоднозначные временные привязки вокруг коммутатора (например, 1:30 утра происходит дважды). Кроме того, при преобразовании часовых поясов большую часть времени вы все равно используете UTC в качестве посредника.

Во-вторых, вы должны решить, является ли ваш сайт международным или нет. Если нет, то вы устанавливаете правила для шести часовых поясов США и заканчиваете его. Три браузера сообщают о временных метках по-своему, это всего лишь 18 случаев, и с ними должна быть возможность справиться. Что-нибудь кроме этого, и вы должны предположить, что это требует повышенной степени, чтобы предвидеть разницу в летнем времени. Время меняется в разные дни в разных местах.

Ваша самая большая проблема с b состоит в том, что, если это приложение, похожее на календарь, планирование все равно будет проблемой, если вы не сможете точно определить, в каком часовом поясе кто-то находится. Например, предположим, что это февраль. Никто не находится на DST. Кто-то планирует что-то на 6 вечера (местное) 5 мая. Видите, смещение - UTC-4. Как вы узнаете, находится ли этот человек в Нью-Брансуике, который наблюдает летнее время (в этом случае время означает , это 2100 UTC), или Пуэрто-Рико, которого нет (в этом случае время означает это 2200 UTC? Это сложный вопрос. Этот пост может помочь.

Answer 3

Пожалуйста, смотрите также эту альтернативу: https://stackoverflow.com/a/12682439/1691517

Обнаруживает 90 часовых поясов и имеет 100% точность на протестированных платформах.

Answer 4

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

Я бы, однако, выбрал вариант A: «выбрать вероятный часовой пояс с правильным смещением» именно потому, что материал с часовым поясом, как правило, сложнее, чем вы ожидаете. особенно если учесть изменения летнего времени. Если вы выберете вариант А, вы можете использовать стандартные функции, предоставляемые PHP.

Вы можете объединить это с другими показателями, чтобы улучшить качество прогнозирования; например:

• На основе статистики посетителей: выберите часовой пояс, откуда приходит большинство посетителей;
• На основе accept_headers: сопоставить язык с часовым поясом;
• на основе IP-геолокации: совпадение со страной в правильном часовом поясе.

Сочетание вышесказанного должно дать вполне разумную оценку. Но 100% -ная уверенность не может быть достигнута.

Answer 5

Если вы хотите положиться на javascript, вы можете просто отправить utc time / timestamp назад и вперед и позволить клиенту преобразовать его в свое местное представление времени.

edit: простой автономный пример (с использованием jquery)

<html>
  <head>
    <title>...</title>
    <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"></script>
    <script type="text/javascript">
      function foo(){
        $('.time').each( function() {
          var t = $(this);
          var d = new Date(Date.parse(t.text()));
          t.text(d.toLocaleString());
        });
      }
    </script>
  </head>
  <body>
    <div class="time"><?php echo gmdate(DateTime::RFC1123); ?></div>
    <button onclick="foo()">local time</button>
  </body>
</html>

Если javascript недоступен, пользователь по-прежнему видит дату / время, хотя оно указано в UTC.
edit2: И есть библиотека javascript (или это был даже плагин jquery?), который делает такие вещи плюс некоторые изящные преобразования, такие как «час назад», «на прошлой неделе»… что-то вроде этого. Но я забыл имя: (