Forum Academy Marketplace Showcase Pricing Features

New features to override timezones

Thanks for your answer :grinning:
My wishful thinking expressed to Grace in this particular case, is avoid hacking (in the good sense) the Bubble functionality by HTML/CSS, and avoid using the geolocale by Google, because it asks the browser permit to let know user location.
Meanwhile, I will try the javascript function provided in your response!

That is unfortunate. The overriding time zone completely via page was a godsend for so many date issues. Really disappointed this is going away. Was the only experimental feature I actually incorporated into an app.

Properly used it was incredible for eliminating time zone issues. :sob:


@boston85719 Yeah, I loved that override.

For anyone confused, here’s what they are deprecating:

Screenshot 2022-11-30 at 12.07.36 PM

I personally loved being able to set this here - I enjoy the extra control this provides. Perhaps I am simply misunderstanding why it needs to be deprecated though. Oh well, glad I can still keep it checked!


To be clear, @guidomazzanti, you don’t need Google geolocation to know the user’s Timezone. It’s simply reported by their browser. The plugin I linked to in my earlier reply simply exposes that Timezone (and related Locale info) in a way that you can access. (It’s extremely lightweight and doesn’t do anything but read those browser properties and make them accessible to you in Bubble expressions.)

Already installed your plugin, thanks you for your contribution to the bubble community :+1:


Hi all - the new version has been released!


I like that this list has been cleaned up, but the ‘Copy with’ should be changed to ‘Copy…’ as the verbiage makes more sense and for some silly reason it gets my brain to second guess what I am clicking especially when I am copying a style which doesn’t have ‘with’ in the statement.

This absolutely destroyed multiple features we launched. We rely heavily on backend workflow scheduling and this was the only way to overcome many of the issues we faced.

I’m about to have a nervous breakdown right now.

@grace.hong Who exactly was interviewed that led you guys to conclude that the override time zones more broadly feature wasn’t needed? Was it random Bubble users or people actively using this feature in their apps? I, for one, was never interviewed or requested to interview about this, though I would have happily done so.

I’m seeing multiple power users in this thread voicing opposition to this depreciation before the final launch of the new version (@JohnMark @boston85719 Why weren’t their voices taken into account in this decision?

It seems like the feature’s actual users are being disregarded here in favor of some vague feedback from non-users about wanting to understand what time zone is being used. By this logic, 98% of bubble functionality should be thrown out because there will always be someone who doesn’t understand how something works and wants it removed to make it “easier to understand.”

Please help us to understand how removing this feature moves the Bubble mission forward or helps Bubble better serve its users. Thanks.


Maybe pause for today though… I agree with you, but you literally replying over and over. Let’s see Monday brings shall we?


I was not interviewed. I build a lot of apps that require a lot of complicated date stuff (complicated but shouldn’t be) and the overriding timezone feature made things a lot less complicated.


From what I understand, Bubble will come up with another more “adequate” solution to compensate in the near future. Yes, the removal of such a feature took me by surprise. Depreciating a super useful function is never a good sign. I had to put everything back the way it was before and not depend on this function. I have my own idea where Bubble will focus on the timezone. One thing is for sure, it’s complicated to understand what’s going on on the server side.


Hey @aj11

I wanted to jump in to add some more context about how we reached our decision to deprecate this feature.

The feedback we used included submitted feedback via the experimental features panel, as well as interviews with new and old users, both of which included individuals who hadn’t interacted with the feature before, as well as those that toggled on and used the feature. Overall, while we did find that users found this second experimental feature to be useful, there were several recommendations around how we could improve the UX, compared to its current state. Therefore, we wanted to remove the feature before we had more users using it as we go back and refine the feature.

Moreover, we originally came up with this second experimental feature as something that’s truly experimental (we noticed a few one-off requests about not being able to control timezone in separate areas, but the feedback was not as concentrated as the original problem we targeted with the first experimental feature). This was something we tried to call out when we released both features.

This set of features is more truly experimental; we do not have a strong commitment to release/not release this feature set as there may be broader improvements that could be made to our platform to support this kind of functionality, rather than one-off changes.

Primarily, we were trying to understand whether there was sufficient interest in such a feature to justify dedicating resources to fully building it out. Through this post, we’ve seen some clear interest, which is helpful to us because now we can justify why we’d want to prioritize the refinement of this feature.

Nevertheless, I do want to apologize for the frustration you’re experiencing. This is our first time deprecating an experimental feature, and going forward, we want to more emphatically signal whether an experimental feature’s purpose is primarily to gauge interest (and no commitment to release), as opposed to refine UX for an eventual release, and will aim to shorten the timeline in which these sort of features are exposed to users.

In the meantime, if you (and other users) are willing, I would be happy to schedule some time to better understand how you’ve been using this feature as we iterate on its functionality!


Thanks for the the thoughtful and thorough response, @grace.hong. It is encouraging to hear that you guys are reevaluating based on the specific interest expressed in this thread.

As you’ve pointed out, there was a fundamental disconnect here on the purpose of experimental features. I’ve only ever seen experimental features move into full release, so I assumed (as I think most Bubble users have) that “experimental” was simply the last step in the QA process for new features Bubble is committed to releasing.

If I had known that experimental features could be discontinued, I would have done two things differently:

  1. Postponed building this feature into the core functionality of my live app until it reached full release.

  2. Provided substantially more feedback (via the experimental panel) to make sure the engineering team knew how excited and eager I was for this feature to go live.

Clearly denoting the intended destination of a feature in its description would help avoid this issue in the future.

The description of experimental features under the “Versions” tab also needs to be updated to make it clear that features can be discontinued if there isn’t enough support for them.

I’d very much like to have a call to discuss the time zone override feature and look at the many date-related problems it was solving for our app. How do we go about scheduling this?


@grace.hong I’m not really affected by time zones, but I do use the experimental parenthesis a lot and I was shocked to see it’s possible a experimental feature can just be discontinued.

I was also under the impression experimental = early access until full release. Hopefully parenthesis make it to full release :pray:

1 Like

@aj11 I’ll DM you to schedule a time this week to chat! Will also communicate to the rest of the product team to more clearly indicate that more experimental features will require clearer indication for feedback + potential discontinued status in the description.
@tylerboodman Here’s my response about parentheses! :slight_smile:

I will say reflecting on this second timezones experimental feature, we should’ve made it much more explicit that we were truly experimenting with this feature.


If someone would explain to me what they need on the backend (vis-a-vis the deprecated experimental feature) that the Parallels SSA doesn’t do, I’d happily update it to fill the gap and put Parallels on sale.

The experimental Bubble date features basically filled the gap that Parallels was designed to address in the first place.

I was really gratified that Bubble (after what 2-3 years?) noticed that users needed a solution for what I call “parallel dates”. Now notice what I’ve said about array math and objects and client side workflows, por favor!

(Bubble people: I’m not upset about that. All of my plugins are basically just peeing on your shoes, saying, “look how easy this is to fix” as I wave a towel in your face.)


I have the same impression…

If Bubble encourages us to upgrade, they should know that our apps, for now on, will be running with these “Experimental features” and we will be counting on it in our further features and deploys.

For me, “Experimental users” were the final line to validate the last details about the “Experimental features” in several “real world” cases.

Now, knowing that they can be removed, i don’t fell safe to test them out anymore…

I will freak out…

1 Like

Thankfully sounds like they are moving forward with the parenthesis feature (how did people survive without it for this long?)

1 Like

Hi Keith, maybe I don’t understand what your parallels plugin does. I looked at it previously, and didn’t seem relevant to my use cases.

There are two situations where I was using the override time zone feature, both in regard to backend API workflows.

The constant between these situations is that these backend workflows in my app can be triggered by both frontend and/or server-side activity. When triggered from the front end, the “API Requests Time Zone” is the local browser time zone of the user. When triggered from server-side, the “API Request’s Time Zone” is UTC.

Consequently, the time zone context of the workflow is unpredictable. It could be any of the local time zones of my users or UTC time.

Without any way of restricting/controlling the time zone, this causes chaos in two scenarios:

  1. When an API Connector Action runs, which includes date values without time zone information. Eg. “12/09/22 10:00PM”. Two different workflow runs, both receiving the same date in text above, can result in two different date values hours apart depending on whether the workflow was triggered by the front end or completely server-side.

  2. When you have a backend workflow that changes the hour of a date to a specific hour in a specific time zone using the “change hour to” operator. For example, I need to generate a date value that is equal to “tomorrow at 10am” in Eastern time. So I use the argument “Current date/time, +days: 1, change hours to 10”. Once again, without the override feature, this one argument can result in different date values based on what triggered the workflow (front-end or server-side).

These use cases could be addressed individually with specific features, but the core issue here is that Bubble does not (though it did for a hot second) allow us to tell an API workflow “use this specific time zone” every time.

It was a beautifully simple solution to a myriad of date-related problems, which is why it was so shocking to me when it was discontinued.

1 Like