Javascript/PHP и часовые пояса
Я хотел бы смочь предположить смещение часового пояса пользователя и применяется ли переход на летнее время. В настоящее время самый категорический код, который я нашел для этого, здесь:
http://www.michaelapproved.com/articles/daylight-saving-time-dst-detect/
Таким образом, это дает мне смещение наряду с индикатором DST.
Теперь, я хочу использовать их в своих Сценариях PHP, чтобы к ouput локальная дата/время пользователя...., но что является лучшим для этого? Я полагаю, что у меня есть 2 опции:
a) Выберите случайный часовой пояс, который имеет то же смещение и DST, сходящий с вывода timezone_abbreviations_list (). Затем назовите date_timezone_set () с этим для применения корректной обработки ко времени.
b) Продолжите рассматривать дату как UTC, но просто сделайте некоторое дополнение метки времени для включения соответствующего числа часов.
Мое чувство состоит в том, что опция B является лучшим способом. Причина этого состоит в том, что с A, я мог использовать часовой пояс, который, хотя корректный с точки зрения offset/dst, может иметь в распоряжении некоторые правила obscur позади сцены, которая могла дать неожиданные результаты (я не знаю ни о ком, но тем не менее я не думаю, что могу исключить его).
Я затем перепроверил бы часовой пояс с помощью JavaScript в начале каждой сессии для получения, когда или изменения часового пояса пользователя (очень вряд ли) или они передают в периоду DST.
Извините за "разгрузку мозга" - я действительно сразу после своего рода заверения, что подходы выше допустимы.
Спасибо,
James.
3 ответа
Если вы хотите полагаться на 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?), Который делает такие вещи плюс несколько отличных преобразований, таких как «час назад», «на прошлой неделе» .. как это. Но я забыл название: (
Хорошо - я нашел его. Спасибо, Брэндон Х., что указал мне на HTML - я не закрыл форму () в сгенерированном HTML, который, по-видимому, отключал IE. Я поднял его и побежал.
Спасибо всем за ваше время.
-121--4859349-vim намного эффективнее с огромными файлами (файлы 100-500MB .csv или .xml в моем случае).
gvim бьет vim hands-down при использовании для сравнения файлов (gvimdiff): установка шрифта (хотите больше контента на экране?), перетаскивание линии разделения окна (хотите видеть больше одного файла, чем другого) и т.д.
Кроме того, я не видел других различий мэра и использовать gvim за исключением работы с большими файлами, потому что я считаю его более удобным в графической среде (gnome).
-121--2360717- Я думаю, что, не зная точного часового пояса, всегда будет шанс, что вы упустите какое-то неясное правило.
Как и в случае с большинством вопросов интернационализации, существует более неясные правила, чем вы ожидаете.
Однако я бы пошел на вариант A: «выберите вероятный часовой пояс с правильным смещением» именно потому, что вещи часового пояса имеют тенденцию быть сложнее, чем вы ожидали. особенно при переходе на летнее время. При выборе варианта A можно использовать стандартные функции, предоставляемые PHP.
Вы можете объединить это с другими метриками, чтобы улучшить качество прогнозирования; Например:
- На основе статистики посетителей: выберите часовой пояс, откуда приезжает большинство посетителей;
- На основе accept_headers: сопоставьте язык с часовым поясом;
- на основе IP-геолокации: сопоставьте страну в правильном часовом поясе.
Объединение вышеизложенного должно дать вполне разумную оценку. Но 100% определенности не достичь.
Если это опрос, то "b" - мой голос.
Во-первых, все время должно храниться в UTC. Это догма. Это очень разумная догма, из тех, о которых вы в конце концов говорите: "Я бы очень хотел следовать этому", после того как ваш проект становится более сложным. Кроме всего прочего, это единственный однозначный, последовательный способ хранения всех точек во времени. Любой часовой пояс с летним временем имеет неоднозначные ссылки на время вокруг перехода (1:30 утра обычно бывает дважды, например). Кроме того, при конвертации между часовыми поясами в большинстве случаев все равно приходится использовать UTC в качестве промежуточного звена.
Во-вторых, вы должны решить, является ли ваш сайт международным или нет. Если нет, то вы создаете правила для шести часовых поясов США и на этом все заканчивается. С учетом того, что три браузера сообщают временные метки своими собственными причудливыми способами, это все равно всего 18 случаев, и с ними должно быть возможно справиться. Все, что сверх этого, и вы должны считать, что для того, чтобы предугадать разницу в летнем времени, требуется высшее образование. В разных местах время переходит в разные дни.
Самая большая проблема с b заключается в том, что, если это приложение типа календаря, планирование все равно будет проблемой, если вы не сможете точно определить, в каком часовом поясе находится человек. Например, предположим, сейчас февраль. Никто не переходит на летнее время. Кто-то запланировал что-то на 6 часов вечера (по местному времени) 5 мая. Вы видите, что смещение составляет UTC-4. Как узнать, находится ли этот человек в Нью-Брансуике, где соблюдается зимнее время (в этом случае время meant равно 2100 UTC), или в Пуэрто-Рико, где его нет (в этом случае время meant равно 2200 UTC)? Это сложный вопрос. Этот пост может помочь.