In a few minutes, we’ll release several new experimental features that provide greater flexibility when working with timezones. You will be able to find these in your experimental features panel (in Settings > Versions) shortly. Thank you to @alex.stanescu for engineering this out
All these features essentially allow the user to specify the timezone in which the date-time is parsed (i.e., evaluated) without having to do math on the original date-time. The first feature provides this ability when a date-time is saved through the Date-Time Picker or Input element. The second feature broadens this ability to other areas of the editor in which date-times are being evaluated and more.
Feature 1: Overriding timezones for date-time inputs
We plan on releasing this feature fully to all our users after receiving usability feedback from the experimental features panel.
The documentation for how this works is located here for Date-Time Picker and here for Input. This feature is a parallel to being able to change the timezone of your date-time in the display (output); now you can change the timezone of your date-time to generate a new absolute time that is stored in your database (input).
As shown in the following screenshot, this feature manifests in two new fields: Timezone selection (Client timezone, Static choice, or Dynamic choice) and Timezone.
Previously on Bubble, date-times were always parsed using the client’s timezone, and you’d have to perform math to if you wanted to interpret the date-time in a different timezone. As an example, if a user in New York (ET) were to enter 6/3/2022 10:00 pm, it’d get read as if the user entered 6/3/2022 10:00 pm ET. If a user in Seattle (PT) were to enter 6/3/2022 10:00 pm, it’d get read as if the user entered 6/3/2022 10:00 pm PT (equivalent to 6/4/2022 1:00 am ET). Therefore, when a user in New York performs a search for data from before 6/3/2022, they’d only get the first entry (6/3/2022 10:00 pm ET) and not the second (6/3/2022 10:00 pm PT).
Now, when your end users are inputting date-times on Date-Time Picker or Input (with Date or Euro Date as the format), you can specify a timezone (statically or dynamically) to override the client timezone when saving the absolute time. If no timezone is specified, the date-time will be parsed in the client timezone as we do today.
Taking the example above, let’s say you want to override the client timezone with Eastern Time. For both the New York and Seattle users entering 6/3/2022 10:00 pm, the date-time will now be stored as the same absolute time: 6/3/2022 10:00 pm ET (also represented as 6/3/2022 7:00pm PT, etc.).
Note that when you are changing the overriding timezone dynamically, whenever the timezone changes, the display will be parsed in the updated timezone, but the absolute time will stay the same. This also applies to autobinding, so if you change the timezone of autobinded date-times, they’ll maintain the same underlying value but display in the updated timezone. Similarly, if you specify initial content, that content will display in whichever overriding timezone you’ve specified.
Feature 2: Overriding timezones more broadly
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.
This feature set allows you to set an overriding timezone:
- For any page
- For any backend workflow: API workflow, recurring event, and database trigger event
- When using the
See below for an example where you can specify the page’s timezone:
When you open the property editor for a page element, you can use “Time zone selection” to define whether you want to use the user’s current timezone or statically define a timezone. All date-time related operations will evaluate using that timezone. Some examples of where this may matter:
- Formatting a date-time to appear for the end user (can be overridden by the “Time zone selection” field on
- Parsing a date-time from an input (can be overridden by the “Time zone selection” field on the individual Date-Time Picker or Input element)
- Evaluating an expression that uses date-times
Note that if you change the page timezone to something other than “User’s current timezone,” the debugger will display date-times in whatever page timezone is selected.
For any API workflow, recurring event, or database trigger event, you can specify the timezone in which the workflow actions evaluate date-times using the “Time zone selection” field. The default timezone used for evaluation for an API workflow, recurring event, or database trigger event will respectively come from the API request, parent workflow where the recurring event was scheduled, parent workflow/page where the change was triggered. Note that this default behavior is unchanged from how it works today.
The :rounded to operator
When you are rounding a date-time, you can use the operator
:rounded down to and select a timezone using “Time zone selection” to use a timezone different from the page’s timezone (default set to the user’s current timezone).
We’re hoping these new features will unlock more productivity and more intuitive use of date-times on Bubble! Please submit feedback on them 🙂
(I’ll update this thread once they’re fully released in the next few minutes!)