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

Question

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

Answer 1

offset = direction * longitude * 24 / 360

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

Answer 2

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

http://askgeo.com/database/TimeZone

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

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

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

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

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

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

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

http://askgeo.com

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

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

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

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

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

Answer 3

Если вы знаете долготу пользователей, вы полностью знаете каждый аспект времени для них (пренебрегая некоторыми небольшими ошибками, такими как специальная теория относительности и т.д.).Среднее солнечное время - это просто разница между GMT и долготой (перевести часть градусов в минуты, 1 градус = 60 минут).Вы добавляете или вычитаете в зависимости от Востока или Запада.Среднее солнечное время - это в основном более точное время, чем часовые пояса.Дневное и ночное время изменчивы и зависят от широты, поэтому вы используете некоторые приблизительные значения времени восхода и захода солнца с учетом широты, даты и года.Одно это дало бы довольно точное представление о дневном и ночном времени.