I need an api like the Places Autocomplete but with the place timezone in the response. I could use the Places Autocomplete api, to get the place reference from the response, than the Place Details api to get the longitude and latitude and finally the Google Time Zone API to get the place timezone. Can I do this with a single HTTP call?
If you just need the current UTC offset so you can tell what time it is at that place, you will usually find it in the results from the Details API. From the documentation:
utc_offset contains the number of minutes this Place’s current timezone is offset from UTC. For example, for Places in Sydney, Australia during daylight saving time this would be 660 (+11 hours from UTC), and for Places in California outside of daylight saving time this would be -480 (-8 hours from UTC).
However, as some have commented, and as discussed here, the place details API does not always return the time zone offset.
If it is not returned, or when you need the full IANA/Olson time zone id for the location, you will need to call the Time Zone API as you described.
You may also be interested in one of the other methods to obtaining a time zone from a location, which are listed here.
Related
I'm testing some API calls and was delighted to see that the seven-day forecast was including the current day. Around mid-day my time, the seven-day forecast changed and started returning tomorrow as the first day instead.
https://developer.here.com/documentation/weather/topics/example-seven-day-weather-forecast.html
My theory is that the servers are in California (or similar timezone). I'm in Stockholm. It was probably still "yesterday" in the server's timezone when I started playing with the APIs.
Any suggestions on how to fix this? Ideally, I'd like to see an additional parameter allowing me to specify my timezone, or (even better) automatic timezone detection of the requester.
The requester's timezone is not used in the retrieval of the weather data. The reference time(zone) is the local time of the location of which weather data is requested. For the seven days weather forecast, the next day is chosen as the start day if the local time is after 15:00.
Using forecast_hourly as product parameter will give you hourly weather data starting from the current local day and not the next day.
At 6:00am Sydney time, Rory Allan clicks the foofoo button in their browser.
This inserts into the foofoo table with an 8:00pm UTC timestamp in the database of my server.
A lot of people are excited about this foofoo button, and they wanted to see what time of the day Sydney time Rory clicked it.
As I stare at my screen in California and view the status of the click, I want to see that he clicked it at 6:00am, not 1:00pm, which is what I will see if I pull the UTC time from the server and let my browser convert it.
You see, a lot of different people click foofoo, such as Phillip Herman in Germany, or Ivan Efimiov in Russia. And all we care about is the relative time of the day they clicked it, in the location they clicked it, regardless of the viewing location.
I don't know the best way to do this. Do I take the local timestamp and convert it to a string, storing it in addition to the real UTC timestamp? Or is this a common problem with a common resolution that I haven't found? I'm guessing / hoping the latter.
This isn't Language specific. These dates have a long journey:
Unix timestamp > Python date > JSON > Node > Mongo > Node > Browser
Ok, clearly 8:00pm UTC is not enough information. But what do you really want to know?
Is 06:00 enough information?
Look for time-only data types, preferably those that reflect time-of-day, rather than elapsed-time. These are often called LocalTime, TimeOfDay, etc.
Or, use strings in HH:MM format (on a 24-hour clock)
Or record the total number of minutes as an integer (60 * HH) + MM.
Or if you need a higher precision, then use seconds, or milliseconds, or microseconds, etc...
Is 06:00 Australia/Sydney enough information?
Store the time as mentioned earlier and store the time zone name in a separate string.
But be careful, because without a date you don't know if UTC+10 or UTC+11 was in effect.
Is 06:00+10:00 enough information?
You could look for a time with time zone data type, such as the one that exists in PostgreSQL, though even the PostgreSQL docs strongly discourage using this type.
Instead, store the time and offset as separate components.
Be careful, because you'd not necessarily know if this data was from Sydney. There are other time zones with UTC+10 at parts of the year too.
Assuming you have the date, such as today, then:
Is 2017-05-31T06:00 enough information?
Store the date and time together in a component that is sometimes called DateTime or LocalDateTime in various languages - but be careful that it is not bound to any specific time zone. Use DateTimeKind.Unspecified in .NET, or "naive" DateTime's in Python, etc.
For MongoDB and others that don't have such a type, use a string in ISO8601 format.
Be careful, because this time could come from anywhere in the world. Nothing here relates it to a specific point in time.
Is 2017-05-31T06:00+10:00 enough information?
Some languages and databases have a DateTimeOffset or OffsetDateTime type for this purpose.
If not, you can store a "Unix Timestamp" and also store the offset from UTC separately.
Or you can just store a string in ISO8601 format with the offset included - just be very careful with regard to comparisons / sorting.
Is 2017-05-31T06:00 Australia/Sydney enough information?
Store separately the date+time component from the time zone.
Consider that a time may be ambiguous during a DST fall-back transition.
Is 2017-05-31T06:00+10:00 Australia/Sydney enough information?
Here we have everything we might possibly need. Use a ZonedDateTime in Java/Joda-Time/Noda-Time, or an "aware" DateTime in Python (pytz, dateutils, etc.), or similar types when they exist in your platform.
Watch out for timestamp with time zone, as you might expect it to store the time zone and it typically does not (despite the name).
If not available, then consider storing a Unix timestamp and separate the time zone name as a string.
As you can tell - there are a LOT of options, and it really depends on exact use case and features available in each language/platform. You'll find more details if you search/ask for each one separately.
tl;dr
Exchange date-time values in UTC as strings in standard ISO 8601 format.
Work in UTC
General rule in date-time handling is to think in UTC, work in UTC, log in UTC, share in UTC, and store in UTC. But present in zoned time for the user.
By think in UTC, I mean every programmer needs to learn to stop their parochial thinking about their own particular home time zone. Translating back-and-forth to your own zone to UTC to other zones will drive a person nuts. Think of UTC as The One True Time®. All other zones and offsets are mere variations.
This strategy is much like internationalization. The programmer uses key strings in her own human language to look up string values from the localization tool to present a value (piece of text) in the human language preferred by her user. In date-time handling, the programmer works in UTC but applies a zone preferred by her user for presenting text in the user-interface.
Moment in UTC
The basic Java class for this Instant. The Instant class represents a moment on the timeline in UTC with a resolution of nanoseconds (up to nine (9) digits of a decimal fraction).
So when Rory in Sydney clicks his button, we record an Instant object.
Instant instant = Instant.now() ;
instant.toString(): 2017-06-01T09:24:54.435Z
Zoned
To present that moment to Rory in his own time zone, we apply a ZoneId to get a ZonedDateTime object.
Specify a proper time zone name in the format of continent/region, such as America/Montreal, Africa/Casablanca, or Pacific/Auckland. Never use the 3-4 letter abbreviation such as EST or IST as they are not true time zones, not standardized, and not even unique(!).
ZoneId z = ZoneId.of( "Australia/Sydney" ) ;
ZonedDateTime zdt = instant.atZone( z );
zdt.toString(): 2017-06-01T19:24:54.435+10:00[Australia/Sydney]
Now we have two objects, instant & zdt, that both refer to the same simultaneous moment on the timeline. The only difference is wall-clock time.
If the user in California wants to see the moment of Rory's button click according to Sydney time, then we already have that solution seen above. If not, if the California user wants to see the moment of Rory's button click in her own California clock, then read on.
We can adjust into yet another region’s wall-clock time by applying another time zone.
ZoneId zAmericaLosAngeles = ZoneId.of( "America/Los_Angeles" );
ZonedDateTime zdtAmericaLosAngeles = instant.atZone( zAmericaLosAngeles );
zdtAmericaLosAngeles.toString(): 2017-06-01T02:24:54.435-07:00[America/Los_Angeles]
Now we have three objects that all represent the same simultaneous moment: instant, zdt, and zdtAmericaLosAngeles. One moment, three wall-clock times.
See this above code run live at IdeOne.com.
Time-of-day
If you literally meant you want the time-of-day only, without the date, you can extract a LocalTime object from those objects above.
But think twice about doing this, as presenting a time-only without date and zone can lead to ambiguity and misunderstanding.
LocalTime lt = zdt.toLocalTime();
all we care about is the relative time of the day they clicked it, in the location they clicked it, regardless of the viewing location
If you are really really really sure that is what you want, then combine my advice above. (But I doubt this is a wise way to go.)
LocalTime lt = LocalTime.now( ZoneId.of( "Australia/Sydney" ) ) ; // Current time-of-day in Sydney.
Library for date-time
We have been using the modern java.time classes in examples above. They are exceptional – I mean than literally. They are virtually unique. Virtually all other platforms have terrible support for date-time work. The predecessor to java.time was the Joda-Time project which was ported to .Net platform as Noda Time. Other than java.time & Noda Time, I know of no other decent library on other platforms.
ISO 8601
The ISO 8601 standard defines many sensible practical formats for textual representation of date-time values.
The java.time classes use the standard formats by default when generating & parsing strings. You have been viewing those ISO 8601 formats in examples above. Except for ZonedDateTime which wisely extends the standard by appending the name of the time zone in square brackets.
The T in the middle separates the date portion from the time-of-day portion.
For UTC, the Z on the end is short for Zulu and means UTC.
For offset-from-UTC, you see a plus/minus number of hours and minutes ahead of or behind UTC. A time zone is history of past, present, and future offsets in use by a particular region.
Database
How databases handle date-times varies widely, though poor support is most common. A database driver, such as JDBC drivers, add another layer of behavior. So no way to succinctly address that here. And this topic is already asked and answered in many other pages in Stack Overflow.
If your database lacks serious date-time support, you may be better off storing the ISO 8601 strings with the Z on the end. These values when sorted alphabetical are also in chronological order.
I use ZingChart to show data as a chart. In the char, I show the data following a time which I get from the server. ZingChart is set as default to follow client time.
I found we can set time zone in a chart only as integer value. However, some time zone are UTC+10:30, UTC+04:30...
So how can we set time zone to ZingChart showing correct time? And if that day has Daylight Saving Time, how should I correct it.
JSON scripts
Unfortunately it appears that ZingChart only supports whole-hour time zone offsets. Not only does this not account for time zones with fixed fractional-hour offsets, but it also doesn't properly account for time zones that use daylight saving time.
The example in the documentation says:
... For example, to set the timezone to Pacific Time, you would add: "timezone":-8.
This is incorrect, as Pacific time is only at UTC-8 during standard time. When it's in daylight time, it uses UTC-7.
This is a common mistake. See "Time Zone != Offset" in the timezone tag wiki. My recommendation to the ZingChart developers would be:
Anywhere you support timezone:-8 you should also support fractional hour offsets such as timezone:5.5 or timezone:8.75.
You should also support named time zone identifiers such as "America/Los_Angeles". To make them work, you'll need to provide a function that the developer can hook into. Don't try to implement the function directly, as there are several libraries already available for this. For example, a developer might combine ZingChart with moment-timezone by writing something like:
zingchart.fnTZOffset = function(timestamp, timeZone) {
return moment(timestamp).tz(timeZone).utcOffset() / 60;
}
ZingChart would invoke this function when timezone was a string and would apply the resulting offset to the specific data point.
Without support from ZingChart, there's not much you can do to properly support time zones.
One other solution to the Daylight Savings time issue some ZingChart users have mentioned in the past is MomentJS. http://momentjs.com
When backdating posts, and supplying the backdated_time parameter as UTC in ISO format, the API does pick up the parameter and creates a post, but date-time of the post is significantly off from the original UTC time stamp provided.
For example:
For a post backdated as 2013-12-18T00:53+0000 Facebook generated post that is 19hours off resulting UTC timestamp would be 2013-12-17T05:53+0000
To make it more clear:
Local time (UTC+11): 2013-12-18T11:53+1100
Posted to FB (UTC+00): 2013-12-18T00:53+0000
Resulting in FB post : 2013-12-17T16:53+1100
(assuming FB converts to my local time zone, as it does to the rest
of the posts)
Any help on workaround would be appreciated!
It's a bug in the Facebook Graph API. Facebook seem to be doing a timezone conversion on a time that doesn’t have (can’t have) a timezone. It seems to be relative to US Pacific local time (currently standard time = UTC - 0800).
I'm in US CST (UTC-0600), so the time I submit is always two hours off. As you’re in Sydney, you're on summer time and 19 hours away from Pacific Standard Time (UTC-0800). Beware that when the US Pacific Time Zone switches to summer time in March the offset will change. It will change again when you return back to standard time in April. (I don't have that problem, because I change standard/daylight in sync with PT.) Also beware that Facebook is liable to fix it in the meantime. (If they’re smart, they’ll change the name of the backdated_time parameter and continue to support it for those of us who are working around the bug.)
Put more succinctly: The offset difference is the number of seconds between the local time set on your account and US Pacific Time zone local time, adjusting each for standard and summer time shifts.
You can confirm this by looking at the HTML in the page. At the time stamp, you'll see some HTML that shows their epoch timestamp, which is different from the epoch time you submitted. In my case, I submitted a value of “1391749200”, while the HTML shows a value two hours earlier, “1391742000”:
<abbr title="Thursday, February 6, 2014 at 9:00pm" data-utime="1391742000" class="timestamp livetimestamp">
I don’t see this problem, however, when setting the scheduled_publish_time (future) value.
Use a page token to post. With page token I get correct timing in UTC, the post is displayed adjusted to my timezone (UTC-6, US Central) Tom
I'm using GWT on the client (browser) and Joda Time on the server. I'd like to perform some DB lookups bounded by the day (i.e. 00:00:00 until 23:59:59) that a request comes in, with the time boundaries based on the user's (i.e. browser) timezone.
So I have the GWT code do a new java.util.Date() to get the time of the request, and send that to the server. Then I use Joda Time like so:
new DateTime(clientDate).toDateMidnight().toDateTime()
The trouble of course is that toDateMidnight(), in the absence of a specified TimeZone, will use the system's (i.e. the server's) TimeZone. I've been trying to find a simple way to pass the TimeZone from the browser to the server without much luck. In GWT I can get the GMT offset with:
DateTimeFormat.getFormat("Z").fmt(new Date())
which results in something like "-0400". But Joda Time's DateTimeZone.forID() wants strings formatted like "America/New_York", or an integer argument of hours and minutes. Of course I can parse "-0400" into -4 hours and 0 minutes, but I'm wondering if there is not a more straightforward way of doing this.
You could use java.util.Date's getTimezoneOffset() method. It's deprecated, but that's pretty usual for Date handling in GWT currently.
And AFAIR, you can specify something similar to "UTC+4" in Joda time.
Update: I looked it up, and it's "+04:00". Or use DateTimeZone.forOffsetHours() or even forOffsetMillis().
Gwittir (http://www.gwtsite.com) is a library for GWT that includes many cool utilities, like databinding, animation, reflection, and more. However, there are some other interesting goodies as well like the new Joda Time integration. If you have ever been frustrated by GWT’s lack of java.util.Calendar support, you’ll love this, as it makes it easy to do date manipulations in your applications.
otherwise, there are other ways to get timezone offset with + & -.
import java.util.TimeZone;
use: TimeZone.getDefault().getRawOffset()
this function will return the offset time in millisecond about your phone seeting. For Example, GMT-04:00 is equals to (-4)*60*60*1000 = -14400000.
After some operations to get the number which you want.
I have a similar but slightly different problem I think.
I actually need to store the clients timezone on the server, so that I can send out messages about dates stored in their calendar.
The dates are stored in UTC time in google app engine and of course I can store the current Timezone offset when creating the appointment. The problem comes when for instance I want to send out a summary email with a list of upcoming appointments in it. These appointments need to be offset with the correct Timezone adjustments for the client (Im happy to assume that they are still in the same timezone as when they created the appointment).
The real problem comes with Daylight Savings adjustments, so for instance I might have appointments stored for Saturday 30th October 2010 at 1pm (BST[GMT+60]) and Monday 1st November 2010 at 1pm (GMT).
So as you can imagine, I cant just use the current timezone offset (BST) as that would mean that the appointment on Monday 1st November would be listed as 2pm rather than 1pm (GMT+60)
It occurs to me that the best way to deal with this is just to store the timezone offset with each appointment individually, but I feel it would be much better to be able to determine the original timezone correctly in the first place, then just let java do the correct adjustments.