UTC to Local time conversion

timezone longitude

Hi everybody,
presently i am doing a project which has a controller ,GPS module and LCD display.from gps module iam able to read NEMA strings and displaying lattitude and longitude and time .from gps we get only UTC time ,now i have to convert time from gps to local time,at the same time base on lattitude and longitude i have to find place and display on the LCD.

if anyone have information how to convert UTC time to Local time . help me .i will waiting for reply

There is alot of information regarding this on Google, you just need to have a search around, but here is the basics

UTC is derived from Greenwich London so at 0 degrees longitude the time is whatever UTC says it is regardless of the latitude, this is not 100% correct as some countries and borders make the exact time in any given place a fairly difficult task suited to higher end PC/ARM type systems with access to world maps and such, also some places have daylight saving and some don't, again all added computation, but for the basics you can just assume the following.

The world is divided into 24 slots, 12 behind GMT and 12 ahead of it. Ranging -180 to +180° the - and + are denoted as W or E in the NEMA string i.e 00123.3456,E there is an implied decimal point after the 3rd character i.e the 001. this gives you your longitude degrees, this goes from 000 to 180 and you need to divide it up into 12 slots for each time zone e.g 0-15 is GMT 16-30 GMT+/-1 31-45 GMT +/-2 etc etc you work out if its + or minus by the E or W, E being + W being -

Thus a formular that takes the first 3 digits of the longitude and the E/W direction can be used:


you can then say


you will have to do your own stuff to handle daylight savings and all that stuff possibly using a look up table of latitudes and longitudes in a rough grid to assign places that use the outdated system

HI,
thanks for you reply.where can i get lookup tables.i serched in google but iam unable to get required material. if you have any links please post .

I don't have any direct links to a table, you will have to make your own based upon daylight savings location information and calculate the gps lat/lon position of the country/state concerned

eg. England would be roughly -3 to +3 degrees longitude and 50-59 degrees latitude (very rougly) so it would have a table entry containing those figures i.e -3 to +3 and 50-57 you can then compare the gps location to all of the places you find use daylight saving time and correctly select the right offset for time

How about simply prompting the user to enter the time zone? I don't think you can automatically and reliable calculate it. For example, U.S. president Bush recently changed the Daylight Saving Time dates. If your clock didn't know that, then its local time display would sometimes be off by an hour.
http://webexhibits.org/daylightsaving/b.html

Be careful not to mix up GPS time and UTC time. They are not the same.
http://tf.nist.gov/general/precision.htm

echo47 said:

How about simply prompting the user to enter the time zone? I don't think you can automatically and reliable calculate it. For example, U.S. president Bush recently changed the Daylight Saving Time dates. If your clock didn't know that, then its local time display would sometimes be off by an hour.
http://webexhibits.org/daylightsaving/b.html

Be careful not to mix up GPS time and UTC time. They are not the same.
http://tf.nist.gov/general/precision.htm

Click to expand...

echo47, yes I think you are right with smaller CPU's we did one for ARM chips not long back and good old bush forced us to issue an update, there are several standard linux libs that will look up lat/lon on quite a detailed map and give back the time zone pretty accurately and we wrote a slightly improved version for an ARM9 core running linux, but it had access to the internet so could automatically update.

I think what would be a good compromise would be to automatically select the time and then ask if daylight saving is in your location at least then it is only a Yes/No input required rather than a full time. You could of course totaly forget about daylight saving and put a sticker on your box saying "We are not in the 1940's any more"

I think for maintaining Lookup table you reqire lot of memory(KB) for that you have to definetly switch to external memory (if you use low mem. controllers). or

just note down world timings of some countries along lat/long dir.then form tables as

first devide N and S then in N - E and W same as in S along timings with reference UTC.i think with this half of the complexcity will reduce.

next in each N-E,N-W & S-E,S-W divisions first check the lat/lon value range(0-180deg) then compare nearst lat/long value(from previously calculated lat-long & UTC+/-time diftables).with that you will get the local time.

ex: let you know lat/long & utc for new delhi(this ex will be clearly understandable if you form sample excel tables).

new delhi: lat- 28deg N,
lon-77deg E for it UTC+5:30.

for process :you entered the test values

lat-25deg N
lon-71deg E

first in lat it will deferentiate N or S obv it's N in lon it's E.
in LAT it will find nearest for 25 i.e 28. and notice UTC diff.
in LON it will compare 71 i.e 77. and note UTC diff.

if both(UTC diff) are equal it will make that as local time.other wise it will took preference one which you will get if you form ref. tables.

Nice idea GMMR, my only comment would be that in my commercial version we only require 128 bytes to store all time zone differentials for 386 countries including daylight saving etc, the trick is to use a slide rule style table, i.e the grid has no fixed x or y relative to GMT, if you allow the grid to be offset per location you can build a very small data set to cover all locations that differ from the standard map of Lon/15 , this system was developed from our head engineers finial thesis study on topological compression systems. Advanced stuff on the face of it but the reality it simply means that a grid based on X,Y can be complimented by assuming X+a Y+b follows the same pattern X,Y accept with an offset, this allows you to define a grid of very high resolution with a very small list of grid locations and offsets.

hi foxabilo,

are you taking about what ever on your first reply or
the lon(0-180 deg) and about your first reply for this topic i tried that logic with local times of different places but i got lots of differences in utc+/-time diff(in most of noted places) compare to what actually they have to be.

can you give an example ? most capital cities are pretty much inline with lat/15

what ever you said on your first reply according to it i told.any way i will give you

ex-1:
for paris long: 2 deg 20' E from what you said

Time Zone = 2/15 = 0.13
let us assume UTC time: TUE 13:05
with that Local time = UTC+TIME ZONE.
LocalTime =13:05+0.13 = 13:18

but the actual time has to be 15:05.

ex-2:
for chatham island long: 176deg 35' W
T.Z = LON/15;
=176/15
= 11:73. min is up to 60 then it be 12:13.
Local time for same UTC time L.T=13:05-12:13= 0:52 any way day diff. will be there.
but actually it has to be 1:50.

if anything is there just tell me.