Я хотел бы угадать смещение часового пояса пользователя и использование дневного света. В настоящее время наиболее окончательный код, который я нашел для этого, здесь:
http://www.michaelapproved.com/articles/daylight-saving-time-dst-detect/
Таким образом, это дает мне смещение вместе с индикатором DST.
Теперь я хочу использовать их в своих PHP-скриптах, чтобы вывести локальную дату / время для пользователя … но что лучше для этого? Я полагаю, у меня есть 2 варианта:
a) Выберите случайный часовой пояс, который имеет те же настройки смещения и DST, что и выход из timezone_abbreviations_list (). Затем вызовите date_timezone_set () с этим, чтобы применить правильное лечение к времени.
b) Продолжайте рассматривать дату как UTC, но просто добавьте некоторое количество времени, чтобы добавить соответствующее количество часов.
Я чувствую, что вариант B – лучший способ. Причина этого заключается в том, что с помощью A я мог бы использовать часовой пояс, который, хотя и правильный с точки зрения offset / dst, может иметь некоторые скрытые правила на месте сцены, которые могут дать неожиданные результаты (я не знаю ни одного, но тем не менее Я не думаю, что могу это исключить).
Затем я перепрограммировал часовой пояс с помощью Javascript в начале каждого сеанса, чтобы зафиксировать, когда изменение часового пояса пользователя (очень маловероятно) или переход к периоду летнего времени.
Извините за дамп мозга – я действительно только после некоторого подтверждения, что вышеприведенные подходы действительны.
Благодаря,
Джеймс.
Чтобы точно определить часовой пояс пользователя, используя javascript. Проверьте jsTimezoneDetect .
Он предоставит вам ключ базы данных часового пояса Olsen, который вы можете использовать для расчетов по дате времени на стороне сервера.
Если это опрос, то «b» – мой голос.
Во-первых, все время должно храниться в UTC. Это догма. Это очень разумная догма, о которой вы в конечном итоге говорили: «Я, конечно, хотел, чтобы я следил за ней», после того, как ваш проект стал более сложным. Между прочим, это единственный однозначный, последовательный способ хранить все моменты времени. Любой часовой пояс с летним временем имеет неоднозначные ссылки времени вокруг коммутатора (например, обычно 1:30 обычно происходит дважды). Кроме того, при переходе между часовыми поясами, большую часть времени вы в конечном итоге используете UTC в качестве посредника.
Во-вторых, вам нужно решить, является ли ваш сайт международным или нет. Если нет, вы делаете правила для шести часовых поясов в США и заканчиваете их. С тремя браузерами, сообщающими временные метки своими собственными ужасными способами, это все еще только 18 случаев, и с ними можно справиться. Все, что за этим стоит, и вы должны предположить, что для этого требуется повышенная степень, чтобы предвидеть различия в летнем времени. Время переключается в разные дни в разных местах.
Ваша самая большая проблема с b заключается в том, что если это приложение, подобное календарю, планирование все равно будет проблемой, если вы не можете точно определить, в каком часовом поясе кто-то. Например, предположим, что это февраль. Никто не участвует в ДСТ. Кто-то планирует что-то для 6 вечера (местного) 5 мая. Вы видите, что смещение – UTC-4. Откуда вы знаете, находится ли этот человек в Нью-Брансуике, который соблюдает DST (в этом случае это означает 2100 UTC) или Пуэрто-Рико, что нет (в этом случае это означает 2200 UTC? Это сложный вопрос. Этот пост может иметь некоторую помощь.
Если вы хотите полагаться на javascript, вы можете просто отправить время / временную метку utc взад и вперед и позволить клиенту преобразовать ее в локальное представление времени.
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?), который делает такие вещи, а также отличные конверсии, такие как «час назад», «на прошлой неделе» .. что-то вроде этого. Но я забыл имя 🙁
Я думаю, что, не зная точную часовую зону, всегда будет шанс, что вы пропустите какое-то неясное правило.
Как и в случае большинства вопросов интернационализации, существуют более неясные правила, чем вы ожидаете.
Тем не менее, я бы пошел на вариант A: «выберите вероятный часовой пояс с правильным смещением» именно потому, что материал часового пояса имеет тенденцию быть более сложным, чем вы ожидали. особенно когда вы учитываете переход на летнее время. Если вы переходите на вариант A, вы можете использовать стандартные функции, предоставляемые PHP.
Вы можете комбинировать это с другими метриками, чтобы улучшить качество предсказания; например:
Сочетание вышеизложенного должно дать вполне разумную оценку. Но 100% уверенности не может быть достигнуто.
См. Также эту альтернативу: https://stackoverflow.com/a/12682439/1691517
Обнаруживает 90 часовых поясов и имеет 100% -ную точность в тестируемых платформах.