Меня попросили указать «правильное» время на нашем веб-сайте, что я, честно говоря, считаю довольно бессмысленным, поскольку «правильное» можно интерпретировать по-разному.
Наш текущий метод определенно приводит к неточному времени, поскольку он использует серверный элемент управления, отображающий JavaScript, который запускается под нагрузкой, используя дату и время с сервера в качестве параметра для создания объекта часов в JavaScript, который, наконец, отображается на странице, а затем начинает увеличивать часы. Между обработкой сервера, сетевой задержкой и производительностью на стороне клиента (есть много других вещей, работающих под нагрузкой) часы оказываются далеко от фактического времени сервера и кто знает по сравнению с клиентским ПК.
Таким образом, чтобы показать «правильное» время, я мог;
- Используйте локальное время ПК и передайте new Date() объекту часов JavaScript. Плюсы: должны быть как можно ближе к часам ПК. Минусы: не уверен, насколько точны часы ПК, не говоря уже о часовом поясе.
- Используйте веб-службу для TCP-запроса к NTP-серверу, чтобы обновить часы на веб-странице. Плюсы: Если локальный ПК также синхронизируется с NTP, будет точное и максимально возможное совпадение. Минусы: придется обрабатывать все настройки часового пояса относительно наших серверов. Если часы ПК не работают, все равно будет несоответствие.
Я реализую свой собственный веб-сервис или использую что-то вроде; Earth Tools или World Time Web Service (EDIT: ссылка удалена — теперь 404)
Вот сообщение в блоге от Джона Галлоуэя о веб-службе атомных часов который довольно старый, но тем не менее высоко оценивается, когда я гуглю, и он не приходит к выводу.
К счастью, я могу выиграть спор с руководством, почему синхронизация с часами нашего сервера (GMT) не имеет смысла, если вы не в этом часовом поясе, и почему нам даже нужно сопоставлять локальный ПК.
Любые углы на этом мне не хватает?