In my client application I have the Latitude & longitude information from skyhook API based on its I.P.
Now based on the latitude and longitude information I need to find out the timezone information of the client. But in the google timezone API documentation https://developers.google.com/maps/documentation/timezone/ I see that timestamp is a mandatory field. In which case what should I need to do.
Also can you kindly help me understand what does the timestamp corresponds to? For e.g :- If my Application server is in U.S.A (say PST timezone) and it makes the google API call passing the server timestamp.
If user logs into client application from India passing lat / long information, to the app server to get the timezone information what will the API provide as dstOffset and rawOffset? i.e If I add the server timestamp with dstOffset and rawOffset will I be getting the client machine timezone information?
I've been scratching my head on Google's Timezone API for a few minutes, specifically on the timestamp parameter. Maybe this will lay out the need:
In San Diego, we (now, in August) have a GMT offset of -8 because of daylight savings time. However, in November we'll have a GMT offset of -7.
So which gmt offset should Google return? -7 or -8? They're both valid, but it depends on what day you take the measurement.
Enter the Timestamp argument. Running the service now, and using a timestamp value of August 2015, I get this response:
{
"dstOffset" : 3600,
"rawOffset" : -28800,
"status" : "OK",
"timeZoneId" : "America/Los_Angeles",
"timeZoneName" : "Pacific Daylight Time"
}
But if I bump the timestamp to November 2015 (once San Diego is out of daylight savings, I end up with this):
{
"dstOffset" : 0,
"rawOffset" : -28800,
"status" : "OK",
"timeZoneId" : "America/Los_Angeles",
"timeZoneName" : "Pacific Standard Time"
}
In both cases the rawOffset is the same, but the DST changed because of the timestamp I provided. If you just want to know the raw timezone, the timestamp doesn't matter.
But if you want an application to reliably do something at 8:00am in San Diego in August and 8:00am in November in San Diego, you'll need to engage the timestamp.
Putting it another way, what's the value of knowing that San Diego is normally -7 hours offset from GMT. If you're working with timezones, you're likely trying to ensure that your UTC time is matched up with what a real person in that location is experiencing. As such, the DST offset is critical.
The documentation link you provided clearly states that the timestamp should be in UTC and that it is used to show the correct DST offset value. It will also control if the timeZoneName
field is shown with "Standard" or "Daylight" in the name.
If you don't care about that and just want the timeZoneId
field, then it doesn't matter what value you pass.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With