Time 从经纬度到GMT的时间偏移的粗略估计

有没有办法估计从纬度/经度到格林尼治标准时间（或时区）的偏移量？我见过geonames，但这需要长期工作，我们不想真正依赖web服务。当向不同的用户提供信息时，它只是用来决定是显示“今天”还是“今晚”，这样就不需要太准确（休息一两个小时也不错）

---

其中，方向为东1，方向为西1，经度为（-180180）

仅基于经度的时区在国际水域之外是非常不准确的。请参见本页上的地图：

深海中的垂直彩色条纹是仅从经度推导出的所谓自然时区，而陆地的颜色则是根据适用法律确定的实际时区。你可以看到他们根本排得不好

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

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

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

• GeoNames.org有一个庞大的点位置数据库（城市中心、机场、公共建筑等），每个点位置都有一系列有用的元数据注释，包括奥尔森时区ID。它们有一个很好的API，让您可以通过web访问这些点位置。问题在于，除非您要查询的点正好位于其数据库中记录的顶部，否则您可能会得到位于时区边界另一侧的结果，或者如果您的查询距离最近的点很远，则可能根本得不到响应。web服务的速度也慢得令人痛苦，它们将您一天可以进行的查询数量限制在相对较小的数量

• 地球工具(http://www.earthtools.org/webservices.htm)还有一项服务，它比GeoNames快得多，但它只返回GMT的偏移量，而不是时区ID，而且它不能正确处理世界上大多数地区的夏令时。而且，它似乎没有被维护，所以我不确定数据是否准确（时区随时间变化）

在回顾了这些选项并搜索了其他可能性之后，我决定构建自己的解决方案，并在以下网站发布了该解决方案：

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

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

当我们第一次发布它时，我们在谷歌应用程序引擎（GAE）上构建了它，并向所有用户免费提供。这是可能的，因为当时GAE的价格很低。从那时起，我们的服务器负载大幅增加，GAE的价格也大幅上涨。这两个因素共同导致我们转向亚马逊网络服务进行托管，并开始对商业用途收费，同时为非盈利、非商业开源项目和研究人员提供免费服务。对于商业用户，我们提供1000个免费查询，让潜在客户评估API，以确保它满足他们的需求。有关定价和条款，请参见网站

底层库是用Java编写的，由于大众的需求，我们还根据商业许可证发布了该库。图书馆的完整文档和定价详细信息可在网站上找到

---

我希望这是有用的。这对我正在进行的项目来说无疑是有用的。

如果你知道用户的经度，你就完全知道他们时间的各个方面（忽略一些小错误，如狭义相对论等）。平均太阳时间只是GMT和经度的差（将度部分转换为分钟，1度=60分钟）。您可以根据东或西进行加减。平均太阳时间基本上比时区更准确。白天时间和夜间时间是可变的，取决于纬度，因此您可以使用一些日出和日落时间的近似值，包括纬度、日期和年份。仅此一项就可以提供相当准确的白天和夜晚的概念。

这很酷，没想到会这么简单，但到目前为止，它似乎相当准确。谢谢。@ravun，这是正确的，因为a）地球有360度的经度，b）在24小时内旋转360度。（：考虑到时区边界通常位于国家边界，这是相当正确的。否则，我每天上班时都要调表，回家时也要调表：-）此外，夏令时取决于当地立法。但对于今天/今晚的问题，它应该足够了。关注问题的主要领域是太平洋，那里的时区边界存在一些相当极端的扭曲。圣

offset = direction * longitude * 24 / 360