粗略估计从纬度到 GMT 的时间偏移答案

【问题标题】：rough estimate of the time offset from GMT from latitude longitude粗略估计从纬度到 GMT 的时间偏移
【发布时间】：2010-11-06 16:45:52
【问题描述】：

有没有办法从纬度/经度估计 GMT（或时区）的偏移量？我见过地名，但这需要长期有效，我们真的不想依赖网络服务。它只是用于在向各种用户提供信息时确定是显示“今天”还是“今晚”，所以它不需要太准确（一两个小时也不错）。

【问题讨论】：

标签： time latitude-longitude offset

【解决方案1】：

offset = direction * longitude * 24 / 360

其中方向为 1 表示东，-1 表示西，经度为 (-180,180)

【讨论】：

这很酷，没想到会这么简单，但目前看来还算准确。谢谢。
@ravun，这在定义上是正确的，因为 a）地球有 360 度经度，并且 b）在 24 小时内旋转 360 度。 (-:
这是合理正确的，因为时区边界通常放在国家边界上。否则，我必须每天上班时设置手表，回家时再设置一次:-) 此外，夏令时取决于当地法律。但是对于今天/今晚的问题，应该就足够了。
关注问题的主要区域是太平洋，那里的时区边界存在一些相当极端的扭曲。尽管如此，即使是那些也会让你在几个小时内到达。
这非常不准确。请参阅askgeo.com/database/TimeZone 上的地图，以及我在下面的帖子了解更多详细信息。

【解决方案2】：

在国际水域之外，仅根据经度来确定时区是非常不准确的。请参阅此页面上的地图：

http://askgeo.com/database/TimeZone

深海中垂直的彩色条纹是仅从经度得出的所谓自然时区，而陆地的颜色是根据管辖法律的实际时区。你可以看到他们根本没有很好地排列。

实际上，我在从事另一个项目时遇到了这个问题，并对其进行了大量的研究和开发。首先是我的研究：

首先，时区通常不会仅通过与 GMT（又名 UTC）的偏移量进行编码。这没有考虑夏令时，以及多年来时区的变化。相反，时区 ID 用于指定一个地理区域，在该地理区域中，官方时钟时间在给定时间段内（例如，自 1970 年以来）在整个区域内都是相同的。此类 ID 最重要的系统是 Linux 和其他 Unix 操作系统使用的“Olson time zone ID”（这些 ID 及其偏移规则一起称为“tz 数据库”）。大多数编程语言和操作系统都对 Olson 时区 ID 提供本地或第三方支持。

就现有的将经纬度转换为时区的解决方案而言：

GeoNames.org 有一个庞大的点位置数据库（城市中心、机场、公共建筑等），每个位置都用一堆有用的元数据进行注释，包括奥尔森时区 ID。他们有一个很好的 API 可以让你通过网络访问这些。问题是，除非您查询的点正好位于他们数据库中的记录之上，否则您可能会得到位于时区边界另一侧的结果，或者如果您的查询可能根本没有响应离他们最近的点很远。 Web 服务的速度也非常缓慢，而且它们将您一天内可以进行的查询数量限制在相对较少的范围内。
Earth Tools (http://www.earthtools.org/webservices.htm) 也有这方面的服务，它比 GeoNames 快得多，但它只返回与 GMT 的偏移量，而不是时间区域 ID，并且它不能正确处理世界大部分地区的夏令时。另外，它似乎没有维护，所以我不确定数据是否准确（时区随时间变化）。

在审查了这些选项并寻找其他可能性但没有成功后，我决定构建自己的解决方案，并将其发布在：

http://askgeo.com

AskGeo 基于世界时区地图，因此它为每个有效纬度和经度返回一个有效时区。它返回用于 Linux 和大多数其他操作系统和编程框架的标准 Olson 时区 ID（例如，“America/Los_Angeles”）。它还返回当前偏移量，充分考虑夏令时。

它非常易于使用，并且在网站的主页上记录了使用情况。该 API 支持批量查询，因此如果您需要进行大量查找，请使用批量接口，而不是让我们的服务器因串行请求而陷入困境。批量查询也快得多，所以每个人都赢了。

当我们第一次发布它时，我们在 Google App Engine (GAE) 上构建它，并向所有用户免费提供。这是可能的，因为当时 GAE 的价格非常低。从那时起，我们的服务器负载大幅增加，GAE 的价格也一路上涨。这两个因素相结合，导致我们转向 Amazon Web Services 进行托管并开始对商业用途收费，同时为非营利、非商业开源项目和研究人员提供免费服务。对于商业用户，我们提供 1000 个免费查询，让潜在客户评估 API 以确保其满足他们的需求。请参阅网站了解定价和条款。

底层库是用 Java 编写的，由于受欢迎的需求，我们还在商业许可下发布了该库。图书馆的完整文档和定价详情都在网站上。

我希望这是有用的。这对我正在进行的项目当然很有用。

【讨论】：

他并没有说他想要时区，而是要知道是白天还是黑夜。使用公认答案中建议的平均太阳时是准确确定这一点的最佳方法之一。

【解决方案3】：

如果您知道用户的经度，那么您就完全了解他们时间的方方面面（忽略狭义相对论等一些小错误）。平均太阳时只是格林威治标准时间和经度的差（将度部分转换为分钟，1 度 = 60 分钟）。您根据东或西添加或减去。平均太阳时基本上比时区更准确。白天和晚上的时间是可变的，并且取决于纬度，因此您可以使用一些日出和日落时间的近似值来考虑纬度以及日期和年份。仅此一项就可以提供相当准确的白天和黑夜概念。

【讨论】：