Подтвердить что ты не робот

Приблизительная оценка смещения по времени от GMT по широте долготы

Есть ли способ оценить смещение от GMT (или часового пояса) от широты/долготы? Я видел geonames, но это должно работать долгое время, и мы действительно не хотим полагаться на веб-сервис. Он просто будет использоваться для определения того, показывать ли "сегодня" или "сегодня" при предоставлении информации различным пользователям, поэтому не нужно быть слишком точным (час или два не было бы плохо).

4b9b3361

Ответ 1

offset = direction * longitude * 24 / 360

где направление 1 для востока, -1 для запада, а долгота - (-180,180)

Ответ 2

Основываясь на часовом поясе только по долготе, дико неточно за пределами международных вод. См. Карту на этой странице:

http://askgeo.com/database/TimeZone

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

Я действительно столкнулся с этой проблемой при работе над другим проектом и провел там значительные исследования и разработки. Сначала мое исследование:

  • Во-первых, часовые пояса обычно не кодируются просто смещением от GMT (ака UTC). Это не учитывает летнее время и изменения в часовых поясах на протяжении многих лет. Вместо этого идентификаторы часовых поясов используются для обозначения географической области, в которой официальное время для часов в течение определенного периода времени было одинаковым (например, с 1970 года). Наиболее важной системой таких идентификаторов является "идентификатор часового пояса Олсона" (вместе эти идентификаторы и их правила смещения называются "базами данных tz" ), которые используются Linux и другими операционными системами Unix. Большинство языков программирования и операционных систем поддерживают поддержку сторонних пользователей Олсона или сторонних разработчиков.

С точки зрения существующих решений для преобразования широты и долготы в часовой пояс:

  • GeoNames.org имеет обширную базу данных о точках (центры городов, аэропортов, общественных зданий и т.д.), каждый из которых аннотируется с помощью кучи полезных метаданных, включая идентификатор часового пояса Олсона. И у них есть хороший API, позволяющий вам получить доступ к ним через Интернет. Беда в том, что если только точка, которую вы запрашиваете, находится прямо над записью в своей базе данных, вы можете получить результат, который находится на другой стороне границы часового пояса, или вы не получите никакого ответа вообще, если ваш запрос далеко от их ближайшей точки. Веб-сервис также очень медленный, и они ограничивают количество запросов, которые вы можете сделать за один день, до относительно небольшого числа.

  • У Earth Tools (http://www.earthtools.org/webservices.htm) также есть сервис для этого, и он намного быстрее, чем GeoNames, но он возвращает только смещение от GMT, а не время ID зоны, и он не справляется с летней экономией времени для большей части мира. Кроме того, он, похоже, не поддерживается, поэтому я не уверен, что данные точнее (временные зоны меняются со временем).

После просмотра этих параметров и поиска других возможностей без успеха я решил создать собственное решение и выпустил его по адресу:

http://askgeo.com

AskGeo основан на карте временного пояса мира, поэтому он возвращает действительный часовой пояс для каждой допустимой широты и долготы. Он возвращает стандартный идентификатор часового пояса Olson (например, "America/Los_Angeles" ), используемый в Linux и большинстве других операционных систем и программных сред. Он также возвращает текущее смещение, полностью учитывая летнее время.

Он чрезвычайно прост в использовании, и его использование документируется на главной странице сайта. API поддерживает пакетные запросы, поэтому, если вам нужно делать много запросов, используйте пакетный интерфейс, а не загружайте наши серверы с помощью последовательных запросов. Объемные запросы также намного быстрее, поэтому все выигрывают.

Когда мы впервые запустили это, мы создали его в Google App Engine (GAE) и сделали его бесплатным для всех пользователей. Это было возможно, потому что цены GAE были такими низкими в то время. С тех пор наша загрузка сервера значительно увеличилась, и цены на GAE пошли вверх. Оба эти фактора привели нас к тому, что мы перешли на веб-сервисы Amazon для хостинга и начали взимать плату за коммерческое использование, сохраняя при этом бесплатную услугу для некоммерческих некоммерческих проектов с открытым исходным кодом и исследователей. Для коммерческих пользователей мы предоставляем 1000 бесплатных запросов, чтобы потенциальные клиенты оценивали API, чтобы убедиться, что он отвечает их потребностям. См. Веб-сайт для ценообразования и условий.

Основная библиотека была написана на Java и по популярному требованию, мы также выпустили библиотеку по коммерческой лицензии. Полная документация по библиотеке и сведения о ценах приведены на веб-сайте.

Надеюсь, это полезно. Это, безусловно, было полезно для проекта, над которым я работал.