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).
Asked
Active
Viewed 1.3k times
3 Answers
27
offset = direction * longitude * 24 / 360
where direction is 1 for east, -1 for west, and longitude is in (-180,180)
balpha
- 50,022
- 18
- 110
- 131
-
That's pretty cool, didn't think it'd be that simple, but so far it seems pretty accurate. Thanks. – ravun Jun 29 '09 at 13:52
-
1@ravun, this is correct by defiition given that a) the earth has 360 degrees of longitude, and b) rotates through that 360 degrees in 24 hours. (-: – Rob Wells Jun 29 '09 at 14:02
-
It's *reasonably* correct given that time zones borders are usually put on country borders. Otherwise, I'd have to set my watch each day when going to work, and again when going home :-) Also, daylight saving time depends on local legislation. But for the today / tonight question, it should suffice. – balpha Jun 29 '09 at 14:09
-
The main area to watch for issues is in the Pacific, where there are some fairly extreme contortions in time zone boundaries. Still, even those will get you to within a couple of hours. – Jonathan Leffler Jun 29 '09 at 14:39
-
What about Daylight Savings Time offsets? Simply adding and subtracting timezone offsets is only half the solution. For example, I know that the timezone offset between Brazil and the East Coast of the US is 1, but the actual time difference can be 1, 2 or even 3 hours depending on the DST status of the US at a given time. Given the OP question though, this is definitely a good enough answer. – Andrew De Andrade Jul 13 '11 at 17:12
-
3This wildly inaccurate. See the map on http://askgeo.com/database/TimeZone, and my post below for more details. – James D May 07 '12 at 21:12
-
1@JamesD *Of course* it is wildly inaccurate. Did you even read the comment thread above? And did you read the question? You're not really suggesting calling out to a web service for making the decision whether to say "today" or "tonight", are you? – balpha May 08 '12 at 12:57
-
Parts of China have a time zone that is off by 3 hours. The question said "an hour or two" wouldn't be bad. Also, while the text of the question asks for an approximate method, the title does not. Stack Overflow is a widely used resource and people will be drawn to that title that want an actual solution. If you want to know if it is day or night, you want sunrise and sunset: http://en.wikipedia.org/wiki/Sunrise_equation – James D May 08 '12 at 20:33
-
Thanks for all of the info in comments. Just to reiterate, it really is meant to be a rough estimate and this answer has worked very well for a long time. I've updated the title based on James D's comment. Also, his sunrise equation link looks appropriate for the solution; though, I'm no longer involved in the project now :P – ravun Jul 25 '12 at 00:47
-
is there any way to get Direction – Shakeel Hussain Mir May 01 '17 at 07:07
1
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.
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:
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.
-
He didn't say he wanted time zone but to know iff day or night. Using mean solar time as suggested in accepted answer is one of the best ways to determine that accurately. – marshal craft Jun 21 '18 at 15:38
0
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.
marshal craft
- 439
- 5
- 18