New features to override timezones

It should be in the format of any of the timezones listed when you select “Static choice” for “Time zone selection” - so either America/New_York or EST should work!

2 Likes

Hello @grace.hong

In Backend Workflows only static selection works
not dynamic like “America/New_York” or “EST”.

Do I have to use a specific format instead of using “text” ?

Dynamic selection in “America/New_York” or “EST” formats is not working for me either. Did you find a solution?

1 Like

Using now “EST5EDT” (and others) instead of EST.

1 Like

I’d really enjoy the option to display dates/times in my DB view in different time zones. I’m trying to standardize everything in my app on UTC, but it’s rendering it in my local time zone, which causes unnecessary confusion.

Ditto on the server scheduler.

1 Like

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.

5 Likes

Hi @grace.hong Just to be sure, this will stay? I’m not sure if I see the second feature you talk about.

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.

1 Like

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.

1 Like

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 :grinning:
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. :sob:

5 Likes

@boston85719 Yeah, I loved that override.

For anyone confused, here’s what they are deprecating:

Screenshot 2022-11-30 at 12.07.36 PM

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!

4 Likes

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 :+1:

2 Likes

Hi all - the new version has been released!

2 Likes

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.