粗略估计GMT与纬度经度的时间偏差

Question

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

Answer 1

offset = direction * longitude * 24 / 360

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

Answer 2

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

http://askgeo.com/database/TimeZone

深海中的垂直彩色条纹是仅由经度衍生的所谓自然时区，而土地的颜色是每个治理法则的实际时区。你可以看到他们根本没有排好队。

我在处理不同的项目时遇到了这个问题，并对其进行了大量的研究和开发。首先是我的研究：

• 首先，时区通常不仅仅由GMT（也称为UTC）的偏移量编码。这没有考虑夏令时，以及多年来时区的变化。相反，时区ID用于指定在给定时间段内（例如，自1970年以来）整个区域中官方时钟时间相同的地理区域。这种ID最重要的系统是“Olson时区ID”（这些ID和它们的偏移规则一起被称为“tz数据库”），Linux和其他Unix操作系统使用它。大多数编程语言和操作系统都具有对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的价格上涨。这两个因素的结合使我们转而使用亚马逊网络服务进行托管，并开始为商业用途收费，同时为非营利，非商业开源项目和研究人员提供免费服务。对于商业用户，我们提供1000个免费查询，让潜在客户评估API以确保其满足他们的需求。有关定价和条款，请访问网站。

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

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

Answer 3

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