粗略估计 GMT 与经纬度的时间偏移
有没有办法根据纬度/经度估计与 GMT（或时区）的偏移量？ 我见过地理名称，但这需要长期工作，而且我们真的不想依赖网络服务。 它只是用于确定在向不同用户提供信息时是否显示“今天”或“今晚”，因此不需要太准确（关闭一两个小时也不错）。
Is there a way to estimate the offset from GMT (or time zone) from a latitude/longitude? I've seen geonames, but this would need to work long term and we don't really want to rely on a web service. It'd just be used for determining whether to display "today" or "tonight" when giving information to various users so it wouldn't need to be too accurate (an hour or two off wouldn't be bad).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
其中方向为 1 表示东，-1 表示西，经度位于 (-180,180)
where direction is 1 for east, -1 for west, and longitude is in (-180,180)
在国际水域之外，仅根据经度来确定时区是非常不准确的。 请参阅此页面上的地图：
http://askgeo.com/database/TimeZone 深海是仅根据经度得出的所谓自然时区，而陆地的颜色是根据管辖法律的实际时区。 你可以看到他们根本没有很好地排队。
实际上，我在从事另一个项目时遇到了这个问题，并对其进行了大量的研究和开发。 首先是我的研究：
就现有的将纬度和经度转换为时区的解决方案而言：
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 编写的，由于大众的需求，我们还以商业许可证发布了该库。 该库的完整文档和定价详细信息位于网站上。
我希望这有用。 这对于我正在从事的项目当然很有用。
Basing the time zone on the longitude alone is wildly inaccurate outside of international waters. See the map on this page:
http://askgeo.com/database/TimeZone
The vertical colored stripes in the deep ocean are the so-called natural time zones derived from longitude alone, and the colors of the land are the actual time zones per the governing laws. You can see that they don't line up very well at all.
I actually ran into this problem while working on a different project and did substantial research and development on it. First my research:
In terms of existing solutions to convert latitude and longitude to time zone:
GeoNames.org has a vast database of point locations (centers of cities, airports, public buildings, etc.), each of which is annotated with a bunch of useful metadata, including the Olson time zone ID. And they have a nice API to let you access these via the web. The trouble is that if unless the point you are querying is right on top of a record in their database, you might get a result that is on the other side of a time zone border, or you might get no response at all if your query is far from their nearest point. The web service is also painfully slow, and they limit the number of queries you can make in a day to a relatively small number.
Earth Tools (http://www.earthtools.org/webservices.htm) also has a service for this, and it is much faster than GeoNames, but it returns just an offset from GMT, not a time zone ID, and it doesn't handle Daylight Savings Time correctly for most of the world. Also, it seems to not be maintained, so I'm not sure if the data is accurate anymore (time zones change over time).
After reviewing those options and searching for other possibilities without success, I decided to build my own solution, and have released it at:
http://askgeo.com
AskGeo is based on a time zone map of the world, so it returns a valid time zone for every valid latitude and longitude. It returns the standard Olson time zone ID (e.g., "America/Los_Angeles") used on Linux and most other operating systems and programming frameworks. It also returns the current offset, taking full account of daylight savings time.
It is extremely easy to use and usage is documented on the main page of the site. The API supports batch queries, so if you need to do a lot of look-ups, please use the batch interface rather than bog down our servers with serial requests. The bulk queries are also much faster, so everybody wins.
When we first launched this, we built it on Google App Engine (GAE) and made it free to all users. This was possible because GAE's prices were so low at that time. Since then, our server load has increased substantially and GAE's prices went way up. Both factors combined led us to switch to Amazon Web Services for hosting and to start charging for commercial use, while keeping the service free for non-profit, non-commercial open source projects, and researchers. For commercial users, we provide 1000 free queries to let potential customers evaluate the API to make sure it meets their needs. See the web site for pricing and terms.
The underlying library was written in Java and due to popular demand, we also released the library under a commercial license. Full documentation of the library and pricing details are on the web site.
I hope this is useful. It certainly was useful for the project I was working on.
如果您知道用户的经度，您就完全了解他们时间的各个方面（忽略一些小错误，例如狭义相对论等）。 平均太阳时只是 GMT 和经度的差（将度数部分转换为分钟，1 度 = 60 分钟）。 您可以根据东或西进行加减。 平太阳时基本上是比时区更准确的时间。 白天和夜间时间是可变的，并且取决于纬度，因此您可以使用考虑纬度以及日期和年份的日出和日落时间的一些近似值。 仅此一项就可以提供相当准确的白天和夜晚的概念。
If you know the users longitude, you completely know every aspect of time for them (neglecting some small errors like special relativity etc). The mean solar time is simply the difference of GMT and longitude (convert degrees part to minutes, 1 degree = 60 minutes). You add or subtract based on East or West. Mean solar time is basically more accurate time then time zones. Day time and night time times are variable and depend on latitude, so you use some approximations of sunrise and sunset times taking in latitude and the date and year. This alone would provide fairly accurate notion of daytime and night.