You can use some online services in the network to calculate the time of the longitude and latitude. The api address and format are as follows:
Http://www.earthtools.org/timezone/40.71417/-74.00639
Return Value:
<? Xml version = "1.0" encoding = "ISO-8859-1"?>
<Timezone xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi: noNamespaceSchemaLocation = "http://www.earthtools.org/timezone-1.1.xsd">
<Version> 1.1 </version>
<Location>
<Latitude> 40.71417 </latitude>
<Longpolling>-74.00639 </longpolling>
</Location>
<Offset>-5 </offset>
<Suffix> R </suffix>
<Localtime> 29 Sep 2010 13:44:01 </localtime>
<Isotime> 13:44:01-0500 </isotime>
<Utctime> 18:44:01 </utctime>
<Dst> Unknown </dst>
</Timezone>
Bugs: Sometimes the time returned by the preceding api Based on the longitude and latitude is incorrect, for example, san francisco (37.787539,-122.420654)
For the time obtained through the api above, see: http://www.earthtools.org/timezone/37.787539/-122.420654
San francisco real local time: http://www.timeanddate.com/worldclock/city.html? N = 224
The comparison shows that the localtime returned by the above api is 1 hour different from the actual time.
Why?
There is a dst in this api(For Daylight saving time and Daylight saving time, see:Http://baike.baidu.com/view/100246.htm), hours faster than the standard hour.
How can this problem be solved?
There are many solutions to this problem. For example, we can collect statistics on which regions are used but not where they are used. Then we can generate a table and provide our own APIs. However, the time-saving method is to find a new webservice.
New api: http://ws.geonames.org/timezoneJSON? Lat = 37.787539 & lng =-122.420654; it returns data in json format: {"time": "2010-10-08", "countryName": "United States", "sunset ": "maid", "rawOffset":-8, "dstOffset":-7, "countryCode": "US", "gmtOffset":-8, "lng ": -122.420654, "sunrise": "", "timezoneId": "America/Los_Angeles", "lat": 37.787539}
Time + dstOffset = 2: 09. This is the local time of sfc during my query.