Hey all,
After speaking to new and old users through interviews, we’re deciding to fully release the first experimental feature (“Overriding timezones for date-time inputs”) which provides the capability to override timezones for date-time inputs and deprecate the second experimental feature (“Overriding timezones more broadly”). For apps that have ever toggled on/off the second experimental feature, the feature will remain visible, but it will have a “deprecated” status next to it. This second experimental feature will be removed in our next Bubble version, to which users can manually upgrade so they have full control over their transition.
Through our interviews, we found that users wanted to clearly understand what timezone is being used (before and after overriding) and what timestamp is being created when they’d like to save a date-time using a different timezone for parsing. While the existing design does add a new field to input elements, users found that this field offers more transparency, compared with an operator on an expression or a timezone for a page. Using an operator on a date-time also doesn’t solve the problem of users wanting to parse entire expressions in a particular timezone; in the current design, it’d have to be applied on every date-time (or subsequent operation) or set at the page level to maintain the interpretation and could more easily result in accidental inconsistencies. We’re still cognizant that users face challenges in designating the overriding timezones for date-times entered through non-inputs (API calls, operations, etc.), so we’ll still be brainstorming better designs for a safer feature while deprecating this initial version.
I will update this post when we have the new Bubble version in which the first feature will be released and the second feature will be removed.