Hi @JohnMark, this is the feature that will be removed. If you refresh your page, it should show up as deprecated for apps that have previously used it. When we release Bubble version 20, it will be removed completely, but you can choose to manually upgrade to that version.
The first feature is “Overriding timezones for date-time inputs” which you can see here and will be released as a full feature in Bubble version 20.
Hi @sravani , overriding timezone will not exist anymore? I’m trying to figure out the impact on my app. It will be replaced by something else or back to normal?
@JohnMark The “Overriding timezones more broadly” feature will no longer exist in the new Bubble version (so its functionality will not be replaced), but “Overriding timezones for date-time inputs” will still be available.
Great news that at least one of the two experimental features will be incorporated into bubble releases.
Grace, is it possible to use in our apps the current user’s time zone that bubble is getting from the explorer?
As it is one of the Time zone selection options, perhaps we could also use it as we can use current date?
@guidomazzanti Bubble still doesn’t seem to expose this in the expression builder, but “User’s current time zone” is just Intl.DateTimeFormat().resolvedOptions().timeZone and you can use a plugin like my “Browser Timezone and Locale” to get access to this and other related browser properties. (It’s rather a mystery to me why Bubble wouldn’t simply add expressions to expose this sort of stuff, but there ya go.)
Thanks for your answer 
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. 
@boston85719 Yeah, I loved that override.
For anyone confused, here’s what they are deprecating:
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 
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 @w.fly). 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:
Postponed building this feature into the core functionality of my live app until it reached full release.
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 
