Upcoming Updates to Timezone Handling in the Backend

Hello Alex,

I have a question regarding using dates that are sent to a Server-side Actions.

Currently, all dates used in Fields of a Server-side Action default to the UTC (GMT+0),
when the date values are returned to Bubble, Bubble converts those dates back to the “User’s Current Timezone”. Is there any way to send the “User’s Current Timezone”? This is giving us problems for dates that cross the IDL (International Date Line).

Example:

  • March 17th 2022 8:00 PM (EST) = March 18th 2022 12:00 AM (UTC)
  • March 18th 2022 8:00 AM (EST) = March 18th 2022 12:00 PM (UTC)

In this example, when doing calculations Server-side, what shouldn’t be perceived as the same day for the user is referenced as the same day because of the default Timezone.

Many thanks,
Fabrice

Your example is effectively changing the timezone from the user’s current timezone (which Bubble sets by default) to a different timezone (EST in your example)

I would argue that this is not accurate – in that example, we have a textual representation of the date and we are interpreting it either in EST or in the user’s current timezone.

In general, I think this post in the thread you linked gives a good explanation of what we’re focusing on making possible (as in, they describe what isn’t currently possible).

I believe I do understand how Bubble dates are stored under the hood. A timestamp is essentially just a big integer - an elapsed number of seconds (or milliseconds) since a particular reference date known as the UNIX epoch in UTC. If that’s not correct, set me straight.

That’s 100% correct :slight_smile:

I only hope that something which required a fairly simple feature to remedy is not going to be made more complicated. :grimacing:

I can assure you that we don’t intend to make things more complicated for users!

Hey Fabrice,

Can you give me a little more context for what you’re trying to do? Are you writing a plugin and trying to parse dates in the plugin? Are you using a plugin? Are you using built-in workflow actions that occur serverside? Or are you doing something else?

Hello Alex,

Thanks for the reply. Sorry for not putting more context. Yes, I have a custom Server-Side Action from a Plugin that generates dates in the future based on a date field from the Database. I then filter out specific dates based on another date field that also comes from the Database. What I’m experiencing is the Server-Side script is interpreting all dates as UTC.

Returned values from the Server-Side Action

So in the previous example

  • Variable Last (User Data): March 17th 2022 8:35 PM (EST)
  • Variable Last (Script interpration): March 18th 2022 00:35 (UTC)
  • Variable End (User Data): March 18th 2022 8:39 AM (EST)
  • Variable End (Script interpration): March 18th 2022 12:39 (UTC)

This is generating problems when comparing 2 dates, as the Script interprets them as equal when they shouldn’t be from the User Data point of view.

Thanks for your help,
Fabrice

Understood. What Bubble does now is simply allow one to display the time represented by underlying timestamp in different timezones. The timestamp itself doesn’t change. What I’m saying is that there are times when one does want/need the ability to change the actual timestamp by “changing the timezone to” a specific timezone.

I’m coming at it from a Bubble developer’s perspective. What’s currently presented in the expression editor for any given date type is the ability to change the years, months, date, hours, minutes, and seconds to any arbitrary value; and the result is a date object with a different timestamp. All I’m saying is that it seems perfectly logical and consistent to have a similar “change timezone to” which also alters the underlying timestamp.

(What has to happen “behind the scenes” to accomplish that - such as convert to and from a textual representation of a date - is irrelevant to me as a Bubble developer. And BTW, that’s precisely what the plugin I’m using does, which simplifies date handling for me in the Bubble environment.)

Then I think we’re on the same page but approaching it from a different angle. It seems to me that just having a “change timezone to” operator would address the issue highlighted in that post and enable the handling of floating dates (as well as facilitate the use of Bubble date types as time-only values).

Of course you don’t, but there’s probably more than one way to go about it, so I guess we’ll see. Hopefully, it meets real-world needs without adding confusion or complexity. I think we’re both talking about the same thing, but we each have a different perspective on it.

Thanks for taking the time to explain. Looking forward to trying it out.

1 Like

Hi @fabrice.latour04,

I understand what you mean. The same moment in time is represented by different dates in the 2 different time zones. I think you’re on the right track by asking…

I’m not aware of a built-in Bubble way to do it (maybe someone else knows), but perhaps that’s part of the timezone handling changes planned with this announcement.

As a stopgap measure, you could probably use a JS snippet and the Toolbox plugin to pass the user’s time zone to the SSA…

Intl.DateTimeFormat().resolvedOptions().timeZone

You could then convert from UTC to the user’s local timezone in the SSA.

Just a thought.

1 Like

Hello Steve,

Thanks for giving your insight on this matter (Note: I don’t think options.timeZone is supported by IE). There’s also the Current geographic position's offset from UTC operator, but this requires that I send extra fields and if the User denies Geolocation, this fails. I just find it counterproductive and prone to errors to maintain 2 different time systems, just because the Timezone doesn’t propagate to the SSA.

Currently, I do all the operations I need in the SSA then 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. :slightly_smiling_face: 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. :crazy_face: :smirk:

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!

1 Like

@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.

1 Like

@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

1 Like

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

2 Likes

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

2 Likes

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?

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?

@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?

Hi @sem,

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.

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!

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. :slightly_smiling_face:

(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. :neutral_face:)

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

Anyway, good luck!

2 Likes

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

1 Like