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

offset = direction * longitude * 24 / 360

where direction is 1 for east, -1 for west, and longitude is in (-180,180)

东方向为1,西方方向为-1,经度方向为(-180,180)

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:

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

• First, time zones are not typically encoded by just an offset from GMT (aka UTC). That fails to take into account Daylight Savings Time, and changes in the time zones over the years. Instead, time zone IDs are used to designate a geographic area in which the official clock time has been the same throughout the area for a given period of time (e.g., since 1970). The most important system of such IDs is the "Olson time zone ID" (together these IDs and their offset rules are known as the "tz database"), which is used by Linux and other Unix operating systems. Most programming languages and operating systems have native or third party support for Olson time zone IDs.

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

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.

  GeoNames.org拥有庞大的点位置数据库(城市,机场,公共建筑等中心),每个数据库都注释了大量有用的元数据,包括奥尔森时区ID。他们有一个很好的API,让您通过网络访问这些。麻烦的是,除非您查询的点正好位于数据库中的记录之上,否则您可能会得到位于时区边界另一侧的结果,或者如果您的查询可能根本没有得到任何响应远离他们最近的点。 Web服务也非常缓慢,并且它们将一天中可以进行的查询数量限制为相对较小的数量。

• 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).

  Earth Tools(http://www.earthtools.org/webservices.htm)也有这方面的服务,它比GeoNames快得多,但它只返回GMT的偏移,而不是时区ID,它没有正确处理世界大部分地区的夏令时。此外,似乎没有维护,所以我不确定数据是否准确(时区随时间变化)。

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.

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

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.

它非常易于使用,并且在网站的主页上记录了使用情况。 API支持批量查询,因此如果您需要进行大量查找,请使用批处理界面,而不是使用串行请求使我们的服务器陷入困境。批量查询也快得多,所以每个人都赢了。

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.

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

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.

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

I hope this is useful. It certainly was useful for the project I was working on.

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

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.

如果您知道用户的经度,那么您完全了解它们的每个方面(忽略一些小的错误,如狭义相对论等)。平均太阳时间只是GMT和经度的差异(将度数转换为分钟,1度= 60分钟)。您可以根据东方或西方进行加减。平均太阳时基本上比时区更准确。白天的时间和夜晚时间是可变的,取决于纬度,因此您可以使用纬度和日期和年份的日出和日落时间的近似值。仅这一点就可以提供相当准确的白天和黑夜概念。