Get time zone with GPS?

Hi!

Is there any way to get the time zone where i'm located with the TINYGPS library?

Or does anybody know a reliable way to calculate the time zone based on GPS location?

The GPS satellites always report the time in UTC/GMT - they don't know where you are.
I haven't seen any code that can figure out your timezone from your lat/long. I don't think it would be an easy thing to do and a program to handle the entire world probably wouldn't fit in an Arduino anyway (the 328-based ones anyway).

Pete

el_supremo:
The GPS satellites always report the time in UTC/GMT - they don't know where you are.

Well, strictly speaking they know where you are but the problem is they have no idea where the country boundaries are of which timezone applies to which country. You could get an indication of your offset relative to UTC from the longtitude, and I guess that in most parts of the world the local time zone is unlikely to be more than a couple of hours away from that, but ultimately for you to know which timezone you're in something would have to explicitly tell you which timezone you're in.

A huge database of coordinates vs time zones (and dates for spring/winter daylight-saving/standard switch-over.)

Well, if i travel with my car gps, the time change as soon as i change timezone, same thing for my cell phone... So for sure there is a way to calculate it 'cause some device already do it.

But for sure i know that its something complicated to code, i have already write something to calculate the "aproximate" time zone (not very hard to calculate 'cause each 15 degree = 1 hour) but as PeterH say, the country boundaries are not always aligned with the the time zone..

So that is why i asked if someone have already write a library or something else to detect the time zone based on gps position.

As "Runaway Pancake" say, maybe its possible to find a database of coordinates vs time zones? (i know that this file can be very large and will probably not fit in the small arduino)

I suspect the cell phone is syncing with the cell tower time.

Well, strictly speaking they know where you are

How do they know whether I am listening to them or not? I have two GPS receivers in my room. At the moment they are both off. How does any GPS satellite know whether I have turned one or both of them on?

Pete

Do you expect this to work "everywhere", or just in some limited region where you are ?

If you know the lattitude and longitude, then in theory you can determine your "time zone" if you have a big enough database of
the definitional boundaries of the time zone. For the whole world, this would be a large dataset.

Quote from: el_supremo on Today at 02:31:00
The GPS satellites always report the time in UTC/GMT - they don't know where you are.

Well, strictly speaking they know where you are

Well, strictly speaking, they (the satellites) have not the slightest notion of where you are.

If you want a rough and ready version, you can just use the Longitude. Assume the time zones are 15 degrees wide, centred around Greenwich.
Determine if you are East or West of Greenwich from your Longitude.

Let temp = present longitude location in degrees

If your absolute value of your present location is <7.5 degrees, your time zone value is 0.

Otherwise, your time zone value is int((temp - 7.5) / 15) + 1

The time zone is added or subtracted depending on whether you are East or West of Greenwich.

A quick primer on how GPS works for those that need it. Sorry for the wall of text, but this really is simplified. See the last paragraph for my actual answer to the OP.

Note, this is just for the US GPS system. The ESA's Gallileo, Russia's GLONASS, and China's system (I forget what it is called off the top of my head) all mostly work in a similar way, but some of the details may be different. (And names changed to protect the innocent, etc...)

In the beginning of time all mass and energy was contained in a singlarity... Err... too far. :wink:

The GPS system consists of 3 main parts:

  • 1: A constellation of satellites in different orbits of varying declinations such that at any one time and from any one place on (or around) the Earth a subset of the full constellation is visible and (this is important) unevenly spread across the sky.
  • 2: A operations facility that tracks all the satellites, verifies they work, verify the orbits are good, moves spares from parking orbits to replace malfunctioning satellites, and orders launches of new satellites to replace spares. They maintain the almanac of active satellites, and measure/calculate the ephemeris data (precise orbital data). They periodically update this data to all the satellites. I think this is all run by the US Air Force.
  • 3: A (usually) portable receiver with either an external or an integrated antenna, sometimes more antennas.

We are mainly concerned with parts 1 and 3.
The satellites all transmit a time stamp, an identifier (PRN), the almanac data, and the ephemeris data. The only thing they receive data from is their operations facility.
The portable receiver is just that, a receiver. It doesn't transmit anything back to the satellites. This is a hand-held GPS unit for hiking, the GPS unit built in to your car, a part of your smartphone, a tracking unit on the bus you rode to work/school on for fleet management, a navigational aid on the airplanes flying above your head, your Arduino GPS shield, etc.

The basic way they work is all the satellites' internal clocks are synchronized to what UTC was a few decades ago (it has drifted since then because all the leap seconds applied to UTC since then were not applied to the GPS system).

  • All the satellites transmit a time-stamp.
  • The receiver knows where all the satellites should be relative to each other from the ephemeris data.
  • The receiver gets the time stamp a certain amount of time after the satellite sends it because light only travels so fast (physicists call this "c"). So the same time stamp from two different satellites that are at different distances from the receiver are received at ever-so-slightly (but measurably) different times.
  • Once the receiver is able to figure out how long it took to get the time stamp from the first satellite, it knows that it is positioned somewhere on a sphere around that satellite that has a radius of (the time it took)/(speed of light). For this discussion I'll call this, and similar spheres, a "range sphere".
  • Once the receiver is able to figure out how long it took to get the time stamp from the second satellite, it knows that it is positioned somewhere on a circle that is the intersection of the two range spheres.
  • It follows that once the receiver is able to figure out how long it took to get the time stamp from a third satellite, it knows that it is positioned in one of two points that is the intersection of the three range spheres.
  • For the final magic (Quiz time, who is credited with saying: "Any sufficiently advanced technology is indistinguishable from magic."?), once the receiver is able to figure out how long it took to get the time stamp from a fourth satellite, it knows that it is positioned in the single, unique point that is the intersection of the four range spheres.
  • All additional satellites that the receiver tracks and calculates it's position against are used to correct for errors due to signal reflections, differential refraction through the atmosphere, etc. That is why you see the accuracy go to lower distances as the receiver acquires more satellites.

Now, all this does is give you a position relative to the satellite constellation. The receiver uses the ephemeris to calculate your latitude, longitude, and altitude to an idealized globe reference, and either the almanac or ephemeris (I'm not sure which, but that detail really doesn't matter) to correct the GPS time to UTC. Because the idealized globe reference doesn't actually match precisely the shape of the earth, the altitude can actually look wrong. (I remember recently I was doing some GPS work at NASA's Wallops Island facility in Virginia, and they are on the Atlantic coast. My GPS units were all reporting negative altitude values. I was quite concerned my GPS units were malfunctioning until one of the locals assured me that the reading I was getting is normal for there. While we weren't below the water, we were below the idealized geoid.) In fact, the surface of the ocean (what is normally called sea level) is different depending on where you are, mostly to localized currents, wind, tides, etc. For example, the US Pacific side of the Panama Canal is at a different altitude than the Atlantic (well, Caribbean) side. Granted, only about 8 inches or so (depending on the tides, the Pacific side has up to 20ft tidal difference where the Atlantic side only has about 1ft tidal difference and the tides are out of phase), but there is a difference.

Now, this was just a quick and dirty primer on GPS. All the details are way more complicated (and even some are considered Top Secret by the Air Force.) In order to accurately calculate GPS positioning, the receivers even need to take into account relativistic time dilation. Really amazing what the little lump of silicon underneath that ~1" square ceramic antenna does.

Back to the original question... In order to then figure out what time zone you are in (or what road you are traveling on), the receiver would also need to have detailed mapping information. Knowing longitude alone won't work for time zones. Just look at this timezone map. There is vast overlap both east and west of the ideal timezones. Take western Europe for example. Parts of France and most of Spain are west of longitude 0 (the mid point of GMT/UTC), yet they both use Centeral European time which is GMT+1. (Actually, if you look at the longitudinal extents of GMT well over 90% of France should be in GMT simply by longitude, and the furthest west parts of Spain should really be GMT-1.) You also can't simply go by country, because many countries use multiple timezones. For example, all of USA and it's territories span 8 timezones. From east to west, the US Virgin Islands and Puerto Rico use the first, the continental USA uses the second through the fifth, Alaska uses a sixth, Hawaii uses a seventh even though it is due south from mid-western Alaska, and Guam uses the eighth. There are even some areas in the world that use "half timezones" (my term because I'm not sure what the proper term is). Without detailed mapping information, which takes a lot of storage, there really is no reliable way of figuring out what timezone you are in simply from latitude and longitude. With a sufficiently large SD card, and a robust enough hashing algorithm, you might be able to do this on an Arduino. Probably better to add an Ethernet, WiFi, or GSM shield and query online map sources. Even summer time (or as we stupid Americans confusingly call it "Daylight Savings Time") differs between countries and localities based on local laws. Some parts of the US don't observe summer time, and recently our president G.W.Bush decided it was a good idea (?!) to change it. That move broke all sorts of clocks that had summer time changes fixed in firmware (and required all sorts of operating system patches for computers and computerized devices)...

This message could probably do with a few more rounds of editing. My apologies for any confusing bits, or inaccuracies.

It is possible that you ccould come up with a table-driven algorithm that would cover a limited geography and a very basic handling of DST. Maybe to cover Canada, say. Would some sort of highly regional solution work for you?

I want to cover the whole world, not a small area (like canada only).

Here is the easiest way i found to find time zone...

1: I have to found a list of many cities in the world with coordinate and time zone of each cities (This list is availlable, search google for "cities15000.txt")
2: After that i reduce the size of the list to keep only coordinate+time zone+"does they use advanced time?"
3: Then i calculate witch is the nearest cities in that list and i use this time zone..

I know it is not always very accurate (Exemple: if cities is near a time zone border), but its very easy to do..

The problem now is to enter this list in my arduino. I have ordered a SD card module, maybe its possible to use it?

I,m searching for the best way (and the easiest way) to find time zone, so if someone have a better suggestion, please let me know!

Well, the "best way (and the easiest way) to find time zone" actually depends on your application. If the device is planned to be basically static, use either an SD card or the built in EEPROM save the time zone and summer time rules for where the device will be deployed. If it will only (or primarily) be used in the vicinity of a WiFi hot spot (or near a hotspot capable cell phone), integrate a WiFi shield and (either at deployment or periodically, or after a certain distance has been traveled) requtest the current UCT offset from a web service. If there is the money in the budget for a cheap GSM SIM card with data, use a GSM shield and (again) use the internet to do the lookup.

So, what is the application so we can advise a course of action and help balance the various costs and benefits of the different methods. Also, what is the target Arduino platform for deployment?

Just a FYI.
GPS does not know where you are since you simply receive the passive radio signals provided by the satellites. China developed a system that required that the mobile unit send a signal back to the satellite, and then the satellite would tell you where you are. Shows the difference between the two govts. 8^)

KeithRB:
Just a FYI.
GPS does not know where you are since you simply receive the passive radio signals provided by the satellites. China developed a system that required that the mobile unit send a signal back to the satellite, and then the satellite would tell you where you are. Shows the difference between the two govts. 8^)

Oh, that's how the Chinese system works? Wow, talk about a bottleneck waiting to happen with all the requests coming in. Also the mobile units need to be much bigger (well, their batteries do) to be able to transmit a signal strong enough to reach orbit and not get lost in noise. Silly me I assumed the Chinese system was similar in operation to the other three because it doesn't make sense (to me) to have to try to track all those mobile units. I guess that is why I'm not a Chinese politician. (Unlike other reasons like I'm not Chinese, and don't and never have lived in China...)

AWOL:

Quote from: el_supremo on Today at 02:31:00
The GPS satellites always report the time in UTC/GMT - they don't know where you are.

Well, strictly speaking they know where you are

Well, strictly speaking, they (the satellites) have not the slightest notion of where you are.

True, but the GPS receiver, which is the only part you interact with, does know where you are and this makes it possible to guess the appropriate timezone offset.

http://www.geonames.org offers a web service that does this for you. Useful if you have a static installation perhaps. If you have an SD card, you could store the vectors of the timezone map borders in terms of lat long and figure out which one you're in from that.

Since there are 24 timezones, you could - as a first cut maybe good enough - figure out where the center of each time zone is and go +/- however many degrees. Won't help for Arizona and Indiana, but should generally work OK.

KeithRB:
Since there are 24 timezones

There's a lot more than 24. Have a look here: http://www.worldtimezone.com/
You have 24 full hour possibilities, plus 1/2 hour offsets. Then there's combinations of do/don't observe DST, different date ranges for DST and whether DST is northern hemisphere or southern. I'm not sure how useful a purely longitude-based approximation would be all that great.

I would be more convinced by a localized map -- maybe a bounding polygon around the british isles and a 10 or 12 segment line between CET and Eastern Europe or something like that. Another approximation might be to have a list of the timezone offsets and DST boundaries for 200 principle cities, then choose the rules for the closest city.

I don't think there's going to be a way to get a fully comprehensive timezone map into an Arduino Flash.