粗略估计 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，让您可以通过网络访问这些内容。问题在于，除非您查询的点位于数据库中记录的正上方，否则您可能会得到位于时区边界另一侧的结果，或者如果您的查询，您可能根本得不到响应离他们最近的点很远。该网络服务也非常慢，并且它们将您一天内可以进行的查询数量限制为相对较小的数量。

• 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

如果您知道用户的经度，你完全知道他们的时间每个方面（忽略一些小的错误，如狭义相对论等）。的平均太阳时是简单地GMT和经度的差（度转换部分分钟，1度= 60分钟）。您添加或基于东或西减。平均太阳时间基本上是更准确的时间，那么时区。白天和夜晚的时间是可变的，取决于纬度，让你用走的纬度和日期和年份的日出和日落时间有些近似。仅此一点将提供白天和夜晚的相当准确的概念。