We are releasing another breaking change related to overriding timezones and how we position the Group Focus element. As we mentioned previously in this thread, we are releasing the “Overriding timezones for date-time inputs” feature, which provides the capability to override timezones for date-time inputs. This new Bubble version will also remove the second “overriding timezones more broadly” experimental feature, which is deprecated for all prior versions. Users will be able to upgrade manually, to give you all full control over how you update your apps.
Also in this new version, Group Focus is now positioned relative to the reference element including padding and border, rather than overlapping with padding as it did previously – no change will be observed if the reference element has no padding.
Before:
After:
Once Bubble Version 20 launches later today, you can upgrade to this behavior in the Settings > Versions tab. Please try it out and let us know if you have any questions!
For me, the lesson I’m learning is to keep in mind that all experimental features are just that, experimental. And as such I will avoid implementing complex features in live apps using these experimental features until they are fully released.
I was just so excited to see the feature since I’d been asking for it for so long. Truly gutting to have the functionality you wanted so badly and needed so much dangled out like that and then taken away.
I had plans to convert the core functionality of our app over to relying on it within the next month or so, and I’m now thankful that I didn’t, but there are still multiple features I have to rebuild.
There are partial workarounds I’m already aware of and using in our apps core functionality by formatting dates as text and then converting them back to date values, but it’s complex and prone to errors (particularly later at night/morning when time zone context can push a UTC date value over to a different day entirely rather than just a different time of day). These workarounds also require 2-6 additional workflow steps for the same result. Highly inefficient.
Most of the situations I have involve an API workflow that schedules another workflow that needs to run at a very specific time of day in a specific time zone (whatever time zone my users have set in their settings). This workflow can be triggered from the frontend, or automatically from the backend. Consequently, the “API Request’s Time Zone” for the workflow isn’t consistent. So when you use the “+Hours” or “Change Hours to” operators the results are unpredictable.
The other situation where this was a godsend was properly parsing incoming dates from outside APIs that don’t include a time zone. For example, properly parsing “22/12/09 10:00 AM” to the correct date value based on my user’s set time zone. Without the broad override, there is no way to predict exactly what this date will be parsed to. The workaround is to bring the date in as text and use multiple steps to ensure it gets parsed in the proper time zone context, but it’s so frustratingly more complex and inefficient to do this.
I’m still just in shock. This is just such a step back for no apparent reason. The feature worked flawlessly. Why remove it? Why take it away from us who have built with it? It seems pointlessly cruel. No upside for Bubble, all downside for users.
@aj11 I too see no reason to remove such a great experimental function. It works well. Correcting the situation has been extremely difficult for me and is not finished. I understand your position very well, and especially hours that lie ahead… Maybe @grace.hong can be more specific of the why?
I knew I wasn’t the only one. I’m sure others will surface over the coming weeks as people’s apps start to unexpectedly break and they go searching for answers in the forum as I did.
The users of the feature were not properly warned and notified, much less allowed the opportunity to explain its value to us before Bubble came to this decision. Just posting updates in the forum is not sufficient.
Users of experimental features being depreciated should be directly notified of upcoming depreciations, if not also consulted beforehand to understand how critical the features are to their operations. Just because the majority of Bubble users aren’t using something doesn’t mean a feature isn’t critical.
I believe I’ve been able to patch everything in my app and get it to work with workarounds (this plugin helped), but I’m not even sure yet because there was no way to see a list of all workflows that relied on it (would have been ideal if it was showed in the debugger after upgrading). So now I’m just hoping that everything works and waiting for bug reports to roll in from my users.
I have no idea what process the product and engineering team followed to came to the decision that this feature wasn’t important enough to keep, but it was extraordinarily insufficient.
As I said from one of the breaking changes, we seriously need notice on these fundamental changes. Just because we aren’t forced to upgrade to the codebase with the change, doesn’t mean it’s not impactful.
I’m sure it won’t happen, but Bubble would be very smart to provide their upgrade path in advance of work so users can either comment or at least be alerted… The days of “effective immediately”, need to go.
I still don’t understand why it’s only ever notified in a forum post and not an email to users? There’s plenty of users who don’t frequent the forum and even as a semi-frequent browser of the forum I have missed crucial information from time to time.
And yes, I also agree any breaking change needs plenty of advance notice.
@troy.roberge@aj11@equibodyapp I think the root of the issue here was most people don’t understand what’s going on here – When I read the original post saying this was going to be deprecated, I glazed right over it (and I wager most people on the forum did, except for people who actually read and comprehended what it meant). When I went and de-activated the feature and visually saw what was removed, THATS when I panicked…
In bubble’s defense, this is the first time they deprecated an experimental features. They did say it was experimental. I’m pretty sure they were surprised by the unexpected pushback from folks like yourself that had built the experimental feature into your live app. I do believe they will review how this was handled and will make the necessary changes to ensure this is handled differently in the future.
They have proven that they are willing and able to accept responsibility and keep working towards perfection even though perfection is not attainable.
Why introduce a feature for such a short amount of time, and then remove it? Why remove an optional feature that works great? I need to rely on the timezones inside of my backend workflows to be in Eastern time. This actually feels like such an obvious thing to have in the first place, it’s kind of surprising that it took so long to even be here. Then once it arrived, it got taken away (without consulting the community, even once!)
Bubble: hey! btw, that feature we added a few weeks / months ago - no more! Good luck fixing it!
