Меня попросили отобразить «правильное» время на нашем веб-сайте, что, честно говоря, довольно бессмысленно, так как «правильное» можно интерпретировать различными способами.
Наш текущий метод определенно приводит к неточному времени, так как он использует серверный элемент управления, отображающий JavaScript, который запускается по нагрузке, используя дату и время с сервера в качестве параметра, чтобы создать объект часов в JavaScript, который в конечном итоге рендерится на странице, а затем начинает увеличивать Часы. Между обработкой сервера, задержкой в сети и производительностью на стороне клиента (есть много других вещей, работающих под нагрузкой), часы заканчивают время, не соответствующее фактическому времени сервера, и кто знает, по сравнению с клиентским ПК.
Таким образом, чтобы показать «правильное» время, я мог;
- Используйте локальное время ПК и передайте новый Date () объекту часов JavaScript. Плюсы: должны быть как можно ближе к часам ПК. Минусы: Не уверен, насколько точны часы ПК, не говоря уже о том, в каком часовом поясе.
- Использование веб-службы для запроса TCP к NTP-серверу для обновления часов на веб-странице. Плюсы: если локальный компьютер также синхронизируется с NTP, он будет точным и наилучшим из возможных совпадений. Минусы: придется обрабатывать все настройки часового пояса относительно наших серверов. Если часы ПК не работают, они все равно будут иметь несоответствие.
Я реализую свой собственный веб-сервис или использую что-то вроде; Инструменты Земли или веб-служба мирового времени ( РЕДАКТИРОВАТЬ: ссылка удалена - теперь 404)
Вот сообщение в блоге от Джона Галлоуэя о веб-сервисе Atomic Clock , которое довольно старое и все же занимает высокое место, когда я гуглю, и он не приходит к выводу.
К счастью, я могу выиграть спор с руководством, почему синхронизация с часами нашего сервера (GMT) не имеет смысла, если вы не в этом часовом поясе и почему нам даже нужно сопоставить локальный ПК.
Есть ли какие-то углы, которые я пропускаю?