time - 粗略估计从纬度到 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 最重要的系统是 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 编写的，由于受欢迎的需求，我们还在商业许可下发布了该库。图书馆的完整文档和定价细节都在网站上。

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

Answer 3

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