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

Question

有没有一种方法可以估算经度/纬度与GMT（或时区）的偏移量？我已经看到了geonames，但是这需要长期工作，我们并不真的想依靠Web服务。它只是用于确定在向各种用户提供信息时是否显示“今天”或“今晚”，因此它不需要太准确（一两个小时或两小时不会太差）。

Answer 1

offset = direction * longitude * 24/360 

哪里方向1对东，-1西部，经度为（-180,180）

Answer 2

立足的时区上单独经度是国际水域以外的极不准确。此页面上看到的地图：

http://askgeo.com/database/TimeZone

深海垂直的彩色条纹是从经度单独产生的所谓的自然时区，土地的颜色是按照实际的时区治理法律。你可以看到他们的排队并不好。

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

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

在现有的解决方案，以经纬度转换时区方面：

• GeoNames.org具有点位置的一个庞大的数据库（城市，机场，公共建筑等的中心） ，其中每个都用一堆有用的元数据注释，包括Olson时区ID。他们有一个很好的API让你通过网络访问这些API。麻烦的是，如果除非你查询的点在数据库中的记录之上，否则你可能会得到一个位于时区边界另一端的结果，或者如果你的查询可能没有响应离他们最近的点很远。 Web服务的速度也很慢，并且它们可以将您在一天中可以查询的查询数量限制为相对较小的数量。

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

审查这些选项和搜索没有成功的其他可能性之后，我决定建立自己的解决方案，并发布了它：

http://askgeo.com

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

这是非常容易使用和使用记录在网站的主页上。该API支持批量查询，因此如果您需要进行大量查询，请使用批处理接口，而不是通过串行请求阻塞我们的服务器。批量查询也快得多，所以每个人都会赢。

当我们首次推出这款产品时，我们将其构建在Google App Engine（GAE）上，并免费向所有用户提供。这是可能的，因为当时GAE的价格非常低。从那时起，我们的服务器负载大幅增加，GAE的价格上涨。这两个因素的结合导致我们转向亚马逊网络服务托管并开始收取商业用途费用，同时为非营利性，非商业性开源项目和研究人员免费提供服务。对于商业用户，我们提供1000个免费查询，让潜在客户评估API以确保满足其需求。查看网站的价格和条款。

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

我希望这是有用的。这对我正在进行的项目非常有用。