Upcoming Updates to Timezone Handling in the Backend

[sudsy]

@fabrice.latour04

I use the Bubble operator :filtered to ensure all dates are in the correct Timezone, as Timezones propagate in Scheduled API workflows.

Sounds like a clever work-around. Doesn’t surprise me that IE doesn’t support contemporary API’s. I’m fortunate to not have to worry about that browser any more. If you do…well…my condolences.

[alex.stanescu]

Hi Fabrice,

Sorry about the delayed reply! What you describe sounds like it is something best handled through our bug reporting system. That way we can assign time to do a full investigation of the cause and plan for a fix. Do you mind submitting a bug report for that?

Thanks!

[guy.blueoceans]

@sudsy

Having a :change timezone to operator would also enable me to more easily save time-only values as Bubble date types by converting Bubble dates to a common (the same) timezone regardless of the timezone of the user who entered the value. (Think of merchants across the globe specifying their business hours.) It’s not only an efficient format to store time values, but it makes it easy to create a date range (time range, actually) and check if a particular date (time) value falls within it.

@alex.stanescu I wanted to vocalize my support for @sudsy comments above. I agree 100% with them! For anyone running a booking/scheduling app that requires managing time slots/scheduling times/appointments has absolutely run into a brick wall trying to manage them for users across different timezones using plain vanilla Bubble capabilities. From my experience it can’t done efficiently/smartly in Bubble without code or plugins that specialize in timezone issue. All I will say is that as someone who discovered Bubble 11 months ago I ended up having to spend almost 1 month learning intricacies of time/dates bc I never considered the timezone complexities until well after I started my mvp project & the way Bubble handles everything as-is had certain important limitations. If it were ever possible for Bubble to add enhanced abilities to manage timezone issues for dates/times I would personally welcome that.

I personally use @keith amazing plugin to deal with timezone issues at moment. Worth every penny.

Parallels: Date/Range Transformer Plugin for Bubble, by Keith from GRUPZ

[brett4]

@alex.stanescu Hello, I think I am ok for the most part on this upgrade but I wanted to run a couple of scenarios by you. We currently pull in data from APIs and load them to our databases. We do not specify any timezones (all times are given in UTC UNIX) which we then change on the front end to the either the user’s time zone or a specified timezone.

Since this is kicked off on the backend and loaded directly into the database without a timezone attached to it will it still recognize these datetimes as UTC in the database or will it just assume a timezone?

Similarly, we have another API connection that loads UTC datetimes into our database. Will these still be recognized as UTC in the database or does this now need to be specified?

Thank you!

Brett

[alex.stanescu]

Hey there!

Sorry about the late reply. Yes you’ll be completely good - any timestamp provided as UTC milliseconds is already an absolute time so no parsing is needed on our end

[grace.hong]

Hi all - just wanted to announce that we’ve released new experimental features that give you more control when working with timezones. Learn more here: New features to override timezones

[brett4]

Thanks @alex.stanescu ! One follow up as we just upgraded our development version.

Does this apply to all other versions (except for live) or does it only apply to the development version?

[mghatiya]

Hi @grace.hong @alex.stanescu

I understand that workflow takes timezone of the client when it is invoked, but is it also true if we invoke the workflow manually via backend (Going to “App Data”, selecting some records and choosing “Bulk” option to run that workflow on some objects)?

I have an API workflow (used within my Bubble application, not called from external app). This workflow takes an object as a parameter which has one date field in it.

Within this workflow I do some operation of searching some objects which have some date fields matching with the date fields of passed object with rounding off to date.

This workflow works fine when it is run manually via an interface. However, when I am running it from backend myself (Going to “App Data”, selecting some records and choosing “Bulk” option to run that workflow on some objects), then the date comparison fails as the “round off to date” happens as per the server data time instead of my data time. i.e. Round off to date gives a timestamp which is as per UTC instead of in my timezone. In my timezone the time becomes different and hence matching fails.

All the concerned fields are date objects, and there is no string comparison/parsing.

Is this expected?

[sem]

@sudsy I really appreciate that you share your knowledge about handling a date in Bubble. I have read a bunch of your posts and replies and it seems that a lot of people do not get the real issue.

Although I am getting to understand the issue I am facing, I do hope you can give a 101 on handling date in Bubble.

My issue is, date of birth (DOB). I was under the impression that you can simply store a date field as floating date which means I do not have to worry about timezones. But this seems not possible in Bubble?!

I was trying to understand why saving as UTC timezone would be a solution opposed to having a floating date entry. Is this a solution because you can offset timezones in the front end because you know the UTC timezone in which the date:time was stored in Bubble? If I understood this correctly I can see how you can offset it in the front end and with queries but it does feel cumbersome to do everywhere where needed.

Can you share the current “best practice” on storing a date of birth in Bubble?

[sudsy]

Hi @sem,

@sem

Can you share the current “best practice” on storing a date of birth in Bubble?

You question is rather timely. I don’t know that there has been a “best practice”, but with Bubble’s recent new feature announcement, perhaps there now could be. With this new feature, you should now be able to save/retrieve Bubble dates in any specified time zone (such as UTC) - but only if you use Bubble’s Date/TimePicker input.

To store birthdates, you want to essentially “ignore” the time zone. To do that, one need simply save and display the Bubble date value in the same time zone (which was heretofore not possible with native Bubble).

Exactly which time zone you use doesn’t really matter (although UTC is probably best from the standpoint of convention and consistency), as long as that same time zone is specified both in the Date/timePicker…

 
 
…as well as when formatting the value for output…

 
 
This approach, in effect, “cancels out” time zone related issues.

Good luck.

EDIT

I should add that most “date of birth” use cases wouldn’t care about the time value, so I’d suggest configuring the Date/TimePicker to Date and not Date & Time.

[sem]

Hi @sudsy ,

Thank you! I have been playing today with your suggestions but since we want to wrap the site and publish a mobile app, the Bubble native date/time picker is not what we want.

Your suggestions about timezones and UTC did put me on a track. I now have implemented and tested a solution in which I save the static timezone UTC and when presenting I offset the timezone with a plugin that gives me the timezone of the browser.

So thanks again!

[sudsy]

@sem

since we want to wrap the site and publish a mobile app, the Bubble native date/time picker is not what we want.

Totally understand. That’s why I created my custom pure Bubble time picker. I wanted a different UI.

I will be updating it to leverage the time zone capabilities of Bubble’s new Date/TimePicker element. I’ll wrap it in a reusable and hide it to take advantage of its capabilities without exposing its UI. That will keep my solution custom, “pure” Bubble, and plugin-free.

(I’m a bit disappointed that Bubble’s new time zone functionality is limited to their input element and can’t be used for arbitrary date types, but oh well. Just gotta roll with it. )

I also have a pure Bubble date picker in the works, which I’ll be posting about early next year. It’s really sweet to have full control over the calendar UI with only no-code logic.

Anyway, good luck!

[sem]

@sudsy

Totally understand. That’s why I created my custom pure Bubble time picker . I wanted a different UI.

Beautiful! Thank you so much for sharing. Also pointers how to do it ourselves. Staying away from standard dropdown is a smart move!