Related Error Again: Does Referencing a Location's Time Zone ID Consume Google API Calls?

Ran across what feels like a bit of an oddity today. I’m getting an error (I believe this comes from Bubble, reporting an issue with either the Google Map or Google Geocode API). This shows up in my console:

Uncaught Error: Timezone fetching issue {"errorMessage":"You have exceeded your daily request quota for this API. We recommend registering for a key at the Google Developers Console: https://console.developers.google.com/apis/credentials?project=_","status":"OVER_QUERY_LIMIT"}

But of course, I do have my own API keys set up in Bubble for Maps and Geocoding. So clearly, I’m exceeding either the request-per-second quota or overall daily request quota.

Where it seems this is coming from is that I am, in fact, debugging some issues related to timezones / date-time stuff (always fun!) and so as part of that I have some repeating groups displaying various dates as I work through my issues.

And I’m presenting those dates in various timezones. Specifically, I’m displaying dates in a certain format using a dynamically specified timezone IDs. Those Timezone IDs are coming from an expression like this that’s retrieving the timezone from a GEOGRAPHIC ADDRESS datatype stored in my database:

Like: “Location’s time zone ID”

I would have THOUGHT that a geographic address thing’s “time zone ID” would essentially be STATIC. That this field would in fact only update if one CHANGED THE ADDRESS. However, it looks like Bubble may actually make an API call to Google whenever one references that field.

This seems very strange. Can anyone confirm that that’s actually how fetching a timezone ID works? (i.e., it’s not a static value stored in the database but just reading that value from a geographic location pings the Google API?)

If that’s the case, I guess in my app I’m going to have to add my own field for Timezone ID that I just snag the Timezone ID for the location whenever an address is first created or modified so that I don’t (inadvertently) keep spamming the Google API in question (I assume it’s Geocoding, but it may be the Map API – the error message is unclear on this point).

Anyone ever seen this? If you do a lot of Timezone referencing, this could easily crop up.

And IF this is what’s happening, it really seems like there’s a bug here (unless I’m missinf something).

Hey Keith, I’m interested in the answer too, which I think might have to come from Bubble.

Google API console has the TimeZone API separate from Geocoding. Is it enabled in your project, and if it is, do you see usage and quota for it on the dashboard?

If you don’t have it enabled, would the lookups be using Bubble’s key for dev/testing?

@emmanuel can you clarify how timezone info in Bubble relates to lookups on Google?

I did not realize that this was separated in Google’s console. I’m going to have to check my own settings, but I think I have everything on.

I did not (when first looking at this) see stats for my consumption. (But I’m not super familiar with Googles current interface as I don’t need to visit that stuff a lot!)

-K-

A little more on this: PART of the mystery solved. I did not have “enable billing” on for this service apparently (so not sure of how my quotas might have been). However, I’m glad I discovered this as otherwise I wouldn’t have known that Bubble seems to be calling that API a lot, when it seems (to me) that it should not.

Shouldn’t Google’s timezone API only be pinged for TIMEZONE ID only when a geo address has CHANGED? The timezone ID (not to be confused with time zone) is not a thing that changes at different points in the year.

(For example, my home address is in the timezone ID called “America/Los_Angeles”. This never changes. However, my home address’s time zone NAME does change. Like, currently it’s Pacific Daylight Time. Later in the year, that will change to Pacific Standard Time, of course.)

Anyway, I’m just pointing out a potential optimization. If I seek to retrieve a time zone ID from previously-stored location (geo address type thing), the time zone ID need never be retrieved from Google (except once if the geo address is changed).

I guess a corollary question is: When I retrieve the street name from an geo address stored in my database, that’s not pinging Google Maps API… is it???

That would be koo koo go nuts. (and I’m pretty sure that’s NOT what happens in that case…)

I can sorta see why timezone ID might be this way (API gets pinged), simply because time zone name is dynamic and it might have been assumed that all timezone-related info changes at different times of the year. But it doesn’t.

1 Like

Yes it does, it’s based on a call to Google.

1 Like

If you’re looking to conserve calls, you could probably run this the first time a location is added to your database and store it’s timezone ID in a separate field. Just a thought.

Thanks for the answer which entirely clarifies the situation.

(So, I guess I did the right thing yesterday: I went and added my own timezone ID field to Things that have a geo location field, so I can have a nice, static copy of timezone ID around and only update it when needed [when the address itself is changed].)

Thanks!

Yep, you’re correct. (Already did that.) :+1:

1 Like

Dang, I’m getting this error in the console again today all of a sudden:

Uncaught Error: Timezone fetching issue {"errorMessage":"Keyless access to Google Maps Platform is deprecated. Please use an API key with all your API calls to avoid service interruption. For further details please refer to http://g.co/dev/maps-no-account","status":"OVER_QUERY_LIMIT"}

Despite the Bubble wrapper on this error, this seems to be an “OVER_QUERY_LIMIT” error for Google Timezone API. (I can tell because Timezone queries are, in fact, not working.)

It’s unclear to me how or why this happened all of a sudden. I checked the Google API Console and I do not actually see any overage going on. I even secured and regenerated my Google API keys, updated them in Bubble, and tested.

Doesn’t seem to be a permissions error as I was able to generate one of those intentionally. However, I keep getting this error, which screws up my app (well, parts of it - like I can’t onboard new properties at the moment because I can’t query their timezone and store it).

Anybody else seeing anything like this? The thing I can’t figure out is: This SEEMS to be associated with my key, but there’s no ACTUAL overage situation going on in Google.