Time zone using latitude and longitude

[vasudha shekar]

HI All,

I need to calculate the timezone using latitude and longitude. I read about google timezone apis but it has a limit on the number of times it can be used. The search application cannot call it more than 25000 times every 24 hours.
Currently we have a json mapping from which we pick up the timezone offset but it's not accurate because it does not take daylight savings into account and e have to manually change the value in db.

Could you please suggest any other approach where I don't need to update it manually and for every search I can get the accurate timezone including the daylight savings.

[Ron McLeod]

Are you working with a single device or a fleet of devices?

Is the device constantly moving or is it stationary at times?

What is the speed at which the device moves?

What accuracy do you need?

In how large of an area do you need to operate?

How do you determine the long and lat - GPS?

Does the device always have network connectivity? What types?

[Bear Bibeault]

If you are doing more than queries than allowed by the Google API you need to buy a license. Or perhaps you can buy a database of this information from somewhere?

[vasudha shekar]

Ron McLeod wrote:Are you working with a single device or a fleet of devices?

Is the device constantly moving or is it stationary at times?

What is the speed at which the device moves?

What accuracy do you need?

In how large of an area do you need to operate?

How do you determine the long and lat - GPS?

Does the device always have network connectivity? What types?

The device does not move

it is a search application which is hosted on servers.

It can be hit from anywhere from any country

based on which country the request is coming from and also which time the request is coming from , timezone which we display in the result varies.

Also, if the user has requested for a future query, based on the date in the request, the timezone should be displayed accordingly.

Yes there is network connectivity almost all the time

Longitude and latitude for most of the cities in each country is currently stored in a json which will be picked up every time.

[Paul Clapham]

Your description isn't all that clear, but it sounds like you are using the name of a city as the start of your time-zone calculation. That's a lot different from being given an arbitrary latitude and longitude to find the time-zone of. So you could cache that information once you find it the first time -- the time-zone of a city almost never changes.

[Ron McLeod]

If the device doesn't move, then at most you will only need a single dip to determine the time zone (maybe not even one if the time zone for the device's location is well known).

What you really need is a way to determine when daylight savings time (summer time) starts and ends (if applicable for that time zone).

There are around 80 countries in the world which use daylight savings, so it would not be to burdensome to manually maintain a database -- this would help with your future requirement as well. Otherwise, if you want to use the API to discover when the time offset changes, you would need to dip it once per day at most just past the time of day when the change would occur.

For the time zone related to the users, I would think that the client application/browser can deal with the local time zone and make the appropriate adjustments, or for a browser - request the local time or time zone using javascript.

[vasudha shekar]

Ron McLeod wrote:If the device doesn't move, then at most you will only need a single dip to determine the time zone (maybe not even one if the time zone for the device's location is well known).

What you really need is a way to determine when daylight savings time (summer time) starts and ends (if applicable for that time zone).

There are around 80 countries in the world which use daylight savings, so it would not be to burdensome to manually maintain a database -- this would help with your future requirement as well. Otherwise, if you want to use the API to discover when the time offset changes, you would need to dip it once per day at most just past the time of day when the change would occur.

For the time zone related to the users, I would think that the client application/browser can deal with the local time zone and make the appropriate adjustments, or for a browser - request the local time or time zone using javascript.

Hello,

The user sends a http request to book something on a particular date. The request contains the date which he selects.
Along with the results we also display the timezone.

Currently, this timezone is calculated using the city from where the user sent the request. This city can be found in static json . In the static json, every city is mapped to a timezone. the entry in the json was done manually for each city.

But, if the date sent in the request is a DST , this timezone will be wrong.

[Ron McLeod]

If you simply need to display the correctly adjusted time on a browser, then let the browser take care of that. It already knows the time zone and when to adjust for daylight savings time for its locale.

<html>
    <head>
        <script>
            var currentDate = new Date();
            var futureDate = new Date(currentDate.getTime() + (200 * 24 * 3600 * 1000)); // +200 days
            
            function showMe() {
                document.getElementById("current").innerHTML = 'Current Date: ' + currentDate;
                document.getElementById("future").innerHTML = 'Future Date: ' + futureDate;
            }
        </script>
    </head>
    <body onLoad="showMe()">
        <p id="current" />
        <p id="future" />
    </body>
</html>

For example, my browser shows that the current time is using PST and 200 days in the future, it will be using PDT.
     Current Date: Sun Apr 19 2015 16:08:14 GMT-0700 (Pacific Standard Time)
     Future Date: Thu Nov 05 2015 15:08:14 GMT-0800 (Pacific Daylight Time)

[vasudha shekar]

Ron McLeod wrote:If you simply need to display the correctly adjusted time on a browser, then let the browser take care of that. It already knows the time zone and when to adjust for daylight savings time for its locale.

<html>
    <head>
        <script>
            var currentDate = new Date();
            var futureDate = new Date(currentDate.getTime() + (200 * 24 * 3600 * 1000)); // +200 days
            
            function showMe() {
                document.getElementById("current").innerHTML = 'Current Date: ' + currentDate;
                document.getElementById("future").innerHTML = 'Future Date: ' + futureDate;
            }
        </script>
    </head>
    <body onLoad="showMe()">
        <p id="current" />
        <p id="future" />
    </body>
</html>

For example, my browser shows that the current time is using PST and 200 days in the future, it will be using PDT.
     Current Date: Sun Apr 19 2015 16:08:14 GMT-0700 (Pacific Standard Time)
     Future Date: Thu Nov 05 2015 15:08:14 GMT-0800 (Pacific Daylight Time)

Thanks RON . That's something new !

The code above calculates DayLight savings on it's own because it takes the system time.
What if I have a date for a particular city which is not the system timezone?

[Ron McLeod]

In my example there is no system (server?) Put that code in file on the client platform and run it from here (for example: file:///Z:/html/date-test.html).

For your application, the system would always provide the time to the client/browser as UTC, not knowing/caring what time zone it is in. The client displays the appropriate date/time based on it's locale.

[vasudha shekar]

Ron McLeod wrote:In my example there is no system (server?) Put that code in file on the client platform and run it from here (for example: file:///Z:/html/date-test.html).

For your application, the system would always provide the time to the client/browser as UTC, not knowing/caring what time zone it is in. The client displays the appropriate date/time based on it's locale.

Thanks a lot RON ..That's really helpful !!!

If I have to decide the timezone of a city from my end at the server itself, what is the best thing you would suggest?..

[Ron McLeod]

The server should be timezone neutral and use UTC.