New features to override timezones

Hi everyone,

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 :smiley:

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 :rounded to operator

See below for an example where you can specify the page’s timezone:

Page

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 :formatted as)
  • 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.

Backend workflows

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!)

27 Likes

Woohoo :tada: :partying_face:

Finally can use the date time input with a time zone! Been waiting for this for a while. :raised_hands:

2 Likes

Hi @grace.hong

It will be interesting to have some kind of Forced Timezone per user.
When I travel, no need to make any change.

4 Likes

These features are now live! Check them out under Settings > Versions > Experimental features!

5 Likes

Hey John!

While we don’t have a plan to provide an automatic timezone field for users, you can add a field of type text to your users and then use that field to set the Dynamic Timezone for any date/times you are displaying, or inputs you are inputting, or whatever else :slight_smile:

4 Likes

This might be the most perfect timing for me! Thanks @grace.hong @alex.stanescu

2 Likes

Well that’s what I call timming, have been reading and studying date/time and timezones for the last months and really needed this.

Just bought Paralles @keith plugin to perform this.

Actually, @keith is someone that really needs to try those new features out.

Cograts @grace.hong @alex.stanescu and Bubble team.

6 Likes

Yeah, this is very interesting. I honestly haven’t had much of any time to play around with any of the experimental features, but they all seem to be addressing some really vexing Bubble limitations, which is great.

And @NetoCamarano, thanks for your patronage. Hopefully you still find value in Parallels (e.g., for list handling/generation, date range manipulation, etc.)

@grace.hong is there any particular library being used for this? (E.g., date fns, luxon) Or is this using a custom interface to native browser APIs?

5 Likes

We use an off-the-shelf date library, but for backwards compatibility with existing Bubble date functionality, we’ve had to wrap it with our own code :slight_smile:

5 Likes

Awesome! Spent a lot of time wrangling with this recently and ended up using a plugin that let me set the timezone. Hoping this sticks around and makes it to the product permanently!

3 Likes

This is a HUGE improvement to the way timezones work! Thanks Bubble team :raised_hands:

1 Like

Thanks a mil @grace.hong

Question: Would this solve the problem when a user uploads a CSV using the “Upload data as a CSV” and has dates in the CSV formatted as dd/mm/yyyy. Previously this date format would be switched by bubble to mm/dd/yyyy? As an example, a date 1 July 2022 would be uploaded as 7 Jan 2022.

Update: I’ve tried this and it doesn’t seem to solve the problem.

Hi Jonathan - thanks for sharing this example. This update doesn’t address how dates are parsed using CSV’s. That’s certainly on our mind as a feature request, and I’ve submitted your additional feedback!

2 Likes

Super helpful feature – allowing me to define a static time zone for the date-time picker (which I use for both input and search functions related to dates things occur on) ensures that users can execute searches for things that happen before or after a certain date, without their local time zones throwing things off.

(Also FWIW, for anyone needing a really clear overview of how time works in Bubble, I’d recommend @petter’s guide Understanding Dates And Time In Bubble. It was written before this new feature, but it identifies issues that this feature resolves.)

3 Likes

I have a current issue where I’ve done the formatting to set the time to the current users’ time zone and it’s not adjusting the time. I’m pulling calendar data from the Microsoft Graph API and have confirmed its returning UTC time.

I’ve also tried static choice, Los Angeles and it has no effect. @grace.hong, any idea of the issue here?

Hi Treb,

What exactly is the date/time value returned by the API, and what are you expecting to see? Are you using the API Connector? Some screenshots might be helpful.

Hi @sudsy,

I’m using the Bubble API Connector plugin to call the Microsoft Graph endpoint for two weeks’ worth of calendar events. https://graph.microsoft.com/v1.0/me/calendarView?startDateTime=[startdatetime]&endDateTime=[enddatetime]

The response has start date time and end date time defined as UTC by default.

In the repeating group, I have columns defined for start and end. Each column is formatted as follows.

I’m UTC-7 so I expect to see a meeting start at 12PM but instead I’m seeing a start time of 7PM, which is the original UTC time. I’ve tried the dynamic version option and fed it the time zone and still not correct.

Sooo, what am I missing here? The expected input for the dynamic option doesn’t appear to be documented anywhere so it’s possible that I’m feeding it the wrong value. I’m expecting the Current User’s Time Zone to do the adjustment to UTC-7. If that’s not what it does, I’d suggest a name change.

Thanks!
–Treb

First off, I might be missing something, but I’m not sure the issue you’re experiencing is related to the features announced in this thread. Bubble has always had the ability to specify the time zone in which to display (output) a date value.

That said, the start time in the red rectangle of your second screenshot is May 17, 2022 5:30 PM in LA time zone. Not sure why you’d expect to see noon. (Maybe I’m misunderstanding the issue.)

It’s just the same IANA timezone name/id shown in the static list. The “dynamic” option simply enables you to generate it programmatically.

Sorry mixed up screenshots. The one that is showing as 5:30 PM in the interface is rendering as 12:30am next day, again in original UTC instead of my current Timezone of Pacific UTC-7. The screenshot is the exact config and it’s not adjusting the time as expected. Hope that clarifies the issue.

What data type did you specify for the start and end dateTime fields when you initialized the call in the API Connector?