Issues with Search and Users Timezone ID?

Hey there,

Currently building out a search where a user can search via Languages Spoken (all good), Skills (all good), and by a Timezone ID (ie; Europe/London or America/New York for example).

The issue is with the Timezone ID search which hangs on page load, and leaves an empty field for at least 2 minutes before any data appears in it…

When it does load you can see it is only showing the Timezone IDs which are currently attached to a user. Which is probably a good thing so you don’t have a dropdown with 200 Timezone IDs in it…

These are the settings I have in the Editor…

Are these correct? What would be causing the hang? Is there a much better method to use?

Many thanks

I think the issue is there’s just so many Timezone IDs… it’s going to take a while to populate.

What’s the search & replace doing? (And is the dropdown population faster when you remove that? (Note that what’s going on here is the search for Timezone IDs must complete and then the search/replace is iterating over all of those.)

What you might need to do is build a list of available Timezones in a not real-time manner. Eg, Run an API Workflow or manually trigger a bulk workflow that builds an object like “Timezone List”. So there’s only 1 and you could populate the dropdown via Search for Timezone List:first item’s Timezone ID Names (for example)

So Timezone List just has a list of texts on it (field Timezone ID Names) that you periodically update, rather than building this list dynamically in the page…

ACTUALLY: an even better idea… build this list just once. Then, when a new user signs up, if their TZid is not already in the list on the Timezone List object, add it right then

1 Like

Thanks Keith. With the Timezone ID list (ie; Europe/London, America/New York etc…) do you mean add this in manually?

I do have it where when a user edits their profile and adds their location (ie; St Petersburg, Russia), their Timezone ID is then displayed on their profile when they click Save Updates.

Could I not get the timezone ID added to the User data type when this is done so there is a permanent record, and you’re not calling upon Google each time? Surely this would help speed things up?

The question is how the hell would I do this? :slight_smile:

Many thanks

YNo, I mean computationallly build the list. But don’t do it every time. Build a static copy, see?

Checking out my previous reply. How the heck would I achieve this? :slight_smile: Have tried a few different things with no luck :frowning:

The same way you dynamically construct the list in the dropdown… except:

  1. You will save that constructed list as a new data type and
  2. Do it in a server side workflow (API Workflow)

The concept is you’re making a system variable or system constant. Maybe my explanation here will help?:

@keith Erm. Ok. Still struggling a little. Could you show me an example/preview however small?

If you want a list of current time zones - you can store the Zone ID and Name when you save the user.

Name (Eastern Standard Time etc) might be easier ? Rather than Id.

Then just pull a list of unique elements as text.


Pinging the geo lookup for every address on the database … is not going to be the best way :slight_smile:

I do this in Teamytime to make it faster.


But… Like I said to @marc2 in previous message: Save THAT in the database so you don’t have to do even THAT that search over and over.

@marc2: Make a new data type. Call it “Timezone Dropdown Source” or whatever you like. Give it at least 1 field. Call it “Text” (type text and it is a list).

Now do Nigel’s search. Create a new Timezone Dropdown Source and set its Text to the results of Nigel’s search.

Now never do that again.

When new users sign up, push their Timezone ID onto that Text field. Bubble will remove dupes so u don’t even need logic.

This object can be referred to as:

Do a search for Timezone Dropdown Source:first item’s Text.

See? System constant. Very fast to retrieve. There’s only one of them. Never create another.

This topic was automatically closed after 70 days. New replies are no longer allowed.