Time zone headaches

ihsanzainal84 · 2025-02-20T08:00:27.839Z

Ahh plugins and timezones. I hate dealing with timezones when building plugins.

ramzizi · 2025-02-21T22:43:50.729Z

Hi @adamhholmes ,

Thanks for your advice. I’m still struggling to figure this out, so maybe I can show you one of my more basic issues.

I have a user that sets their availability for booking on a calendar. They pick the dates using date/time picker. It seems like as you suggested, it saves the date ranges in UTC.

image851×456 45.1 KB

Unfortunately my app is very entrenched in using date ranges to display availability. When a user in Asia selects March 3 8am-5pm, it’s getting saved in UTC when ends up saving as something like [“March 2, 2025 3:00pm”, “March 3,2025 12:00am”]

This displays correctly on the vet’s calendar when in Asia. But incorrectly for the hospital. And I just had a real world hospital user who was in a separate time zone from their hospital, so I’m not sure how to display the correct time if I don’t know what time zone the hospital user is going to be in.

The available dates are displayed according to this:

image662×370 32.5 KB

image762×407 33.3 KB

adamhholmes · 2025-02-21T22:48:24.507Z

ramzizi:

And I just had a real world hospital user who was in a separate time zone from their hospital, so I’m not sure how to display the correct time if I don’t know what time zone the hospital user is going to be in.

Just keep EVERYTHING in UTC and you can’t go wrong.

ramzizi · 2025-02-22T21:25:41.211Z

I’ve spent the last day trying to convert everything to UTC. It’s turning into quite an ordeal, I have hundreds of workflows and text elements that need to be reconfigured. This is turning into a crazy amount of work and I’m creating more bugs than I had initially

boston85719 · 2025-02-23T03:04:11.640Z

I think the issue is in how the plugin requires the day of week pattern for setting up available time slots. It looks to be requiring a field value that is a date range, so if the date range is supplied as Sunday Feb 23 from 9PM - 10PM in NYC, it will look as if it is Monday Feb 24 from 9AM - 10AM in Asia timezone, which when put into the Sunday Pattern field value, will end up with the wrong time slots since the plugin likely parses the date range for the day of the week number. This will result in issues with time zones and daylight savings. I could be wrong though as I do not know 100% for sure how the plugin functions or what the field values are supposed to be.

If I am correct than @ramzizi you may want to adjust the data structure you use for storing the availability ranges, so that instead of saving them as it seems they are as separate ranges for separate days of the week, you may store them all in one field as a list of ranges and then provide that single field as the pattern value for each day of week with filters to extract the day of week number from the patterns date range values…this will still be difficult though if the date ranges span hours that will in other timezones change the day of week number (I’m thinking start of range versus the end of range as being different day of week numbers).

adamhholmes · 2025-02-23T08:54:34.984Z

ramzizi:

I’ve spent the last day trying to convert everything to UTC. It’s turning into quite an ordeal, I have hundreds of workflows and text elements that need to be reconfigured. This is turning into a crazy amount of work and I’m creating more bugs than I had initially

Yep…. I’ve had to fix several apps in the past built by others who have also used time zones incorrectly, so I know what’s involved.

That’s why I now just advise using UTC for all dates unless there’s a specific reason why local timezones are needed.

There is no (simple) native Bubble way to convert dates from one time zone to another, so I’d recommend using Luxon (although you can do it with vanilla JavaScript).

One thing I see that catches a lot of people out here, is the use of Current Date/time rounded down to day in UTC, thinking that will give the current local Day in UTC. It won’t (at least not always) and is one of the most common reasons I’ve seen for date issues in the apps I’ve been called on to fix.

sem · 2025-02-23T09:43:04.730Z

To add to @adamhholmes excellent posts it might be helpful to understand why this is good advice. You need to know what a particular moment in time means. So storing everything in UTC at least makes sure you always know what type of time you fetch from your db. From there the only thing left is correcting it for the users time zone. When you have an issue somewhere it is either because you did not convert user input to UTC correctly, did not convert UTC correctly to user time or both.

Last but not least, take a few hours to read about utc, timezones and JavaScript libraries dealing with it. Just to get a good understanding about the challenges. In case your app heavily depends on multiple timezone handling.

gf_wolfer · 2025-02-24T13:39:11.808Z

To help with some confusion here, I would not use other strategies mentioned here in combination with the TopCal Plugin.

The plugin makes it easy to ensure you are always storing and saving things in a specific time zone (but you don’t actually ‘store in a time zone’ rather in unix time… but let’s not go down that rabbit hole here). So mixing in some type of ‘normalized time zone’ strategy would ruin the accuracy. That strategy may work for some, but I would only recommend it for very specific type of applications.

ramzizi:

They pick the dates using date/time picker. It seems like as you suggested, it saves the date ranges in UTC.

This will be incorrect. The plugin is designed to be accurate to time zones. So when you save from an Input, the plugin element ‘Set Availability’ has a field for a time zone that the resource in (location of the hospital in this case). So if the user puts 9am, it will save it exactly 9am in whatever time zone you specify.

The plugin makes it simple if you always input dates/times using the Resources location time zone, and then always display dates/times using the resources location time zone. Full stop. If you try to add logic for where is the user or normalize a time then it will be off. Use the consistent time zone that you want people to interact with the app in all elements and it will be consistent. Once you deviate on a Text element here or a Top Cal element there then it will be off.

Note: since Bubble Version 20, they added a way to change an input’s date/time time zone. The Set Availability element does not recognize this and just takes out the Hours / Minutes / Day. This specifically may have caused some confusion for some users using TopCal

boston85719 · 2025-02-26T15:45:25.327Z

I just released the free template that uses my plugin.

Bubble

ScheduleMe - Calendly Clone Template for Bubble

ScheduleMe - Calendly Clone Template page on Bubble. Use this template to speed up your app development. Bubble lets you build web apps without any code.

In the video below I demonstrate a booking and how the users current timezone is detected and populated by default, but while selecting their desired timeslot, they can choose to change their timezone and the selected date and available timeslots displays are updated to reflect that newly selected timezone.

In the video I also demonstrate the day light savings aware. In my timezone, Asia/Bangkok, we do not follow daylight savings. In NYC it falls around March 9th this year, so I select March 7 and then March 14 to demonstrate the difference in the America/New_York timezone due to the day light savings change.

ramzizi · 2025-02-27T18:06:58.890Z

Thank you @gf_wolfer ,

If you don’t suggest saving dates in UTC, how do you suggest dates are saved using TopCal if I don’t want time zones adjusted? i.e. a user sets their specific date availability as Feb 15 8am-5pm. This is saved and used by TopCal as a date range. But a different user viewing that person’s calendar will see that availability adjusted into their local time zone.

Because these bookings are in person and not virtual, I am trying to get the dates to be static. So Feb 15 8am-5pm as a booking appointment or an availability would be visible to anyone exactly the same.

gf_wolfer · 2025-02-27T18:31:12.072Z

For always using/showing in one time zone:

Use TopCal elements and always set the time zone fields in the ‘TimeZoneX’
For any Text or Input elements always display dates in ‘TimeZoneX’
*never display dates back without setting a time zone or changing it to TimeZoneY

ramzizi:

But a different user viewing that person’s calendar will see that availability adjusted into their local time zone.

Not if you display it back to them in the hospitals time zone.

I will update this page shortly to let you change the Calendar and Time buttons time zones so you can see setting in a single time zone and seeing it back in that same time zone regardless where your browser says you are.

gf_wolfer · 2025-02-28T15:51:10.400Z

@ramzizi this free and open Template now specifically works so you can change the Time Zone display and see that when the two dropdowns are the same you will always see the same 9am start times regardless where you are with your computer. There were a few more elements that need to be adjusted for the time zone than I remembered but still rather simple - just make sure you are consistent with your time zone displaying strategy

Bubble

Bubble - Visual Programming

Build stuff without code and launch a startup without a tech-cofounder! Bubble is a visual programing language. Instead of typing code, use a visual editor to build applications.

note: thanks for bringing this up as when testing I happened to test across an end of month in far off time zones (EDT it is February and in Auckland it is March) and fixed a small bug on the Calendar Dates element. Most people wouldn’t really come across it

hi.luisacosta · 2025-03-01T05:24:04.915Z

I went through a huge headache with this last year.

Surprised this video hasn’t been brought up… it’s all I think about when dealing with these issues.

Enjoy

gf_wolfer · 2025-03-01T12:57:55.403Z

Exactly, that’s why TopCal uses Luxon.js

But then there are still other things that need to be considered depending on specific apps, but the majority of the headaches get solved with a good library

ihsanzainal84 · 2025-03-02T13:49:58.472Z

Regardless of how good a library is, a Bubble plugin still needs to take into account how a Bubble dev feeds and use the variable.

Bubble handles timezones quite decently from my experience. Problems occur when feeding them into the Bubble database. It’s easy to lose track and mismatch timezones.

ramzizi · 2025-03-02T18:12:53.449Z

I’m slowly getting this figured out, I’ll post an update with my solution when I’m done if there’s anyone having similar issues.

For anyone reading this and building their MVP - start paying attention to time zones now! Not after you’ve launched and have to change a hundred workflows and elements while real users run into problems

boston85719 · 2025-03-03T03:49:51.915Z

Exactly. In my free template the plugin that powers it needs simple JSON for day of week availability, and time zone of user who created the availability. Reduces all complexities and known issues when trying to translate a date range saved as availability schedule into a new date for timeslot purposes. This eliminated time zone headaches and Daylight Savings issues and makes for easier cross service integrations.

I had my fair share of struggles with manipulating dates, time zones and daylight savings, now no more.

This simplification also enables my plugin to generate timeslots in a backend workflow. So it’s got the element that processes for free on client side and a server side action for processing in backend workflows, which is great for advanced integrations and scheduling features.

gf_wolfer · 2025-03-03T11:17:10.897Z

ihsanzainal84:

It’s easy to lose track and mismatch timezones

I think this is a the most common issue Bubblers face when testing things out.

When you inspect dates in the Database or with the Debugger it will always show you the Date Time in your current Browser’s time zone which can be confusing since it is actually a UNIX timestamp, and not a static Date/Time as someone might logically think about it. So it likely is the right date/time you want, but looks incorrect because of the way it gets displayed back.

boston85719:

enables my plugin to generate timeslots in a backend workflow

Good work This functionality really opens up possibilities. The TopCal plugin has done this since the beginning as well and I’ve seen some cool ways it can speed up or optimize apps and also allows for API-focused scheduling apps.

ramzizi · 2025-03-08T19:00:07.624Z

Hi @gf_wolfer ,

I’m still working on this issue and I’ve encountered a little confusion in regards to the GetAvailableTimeSlots element time zone setting.

I have a Specific Date set in Schedule as [March 20, 2025 5:00am, March 20, 2025 2:00pm]

I have the element set to a user’s home address time zone like this:

image335×812 21.5 KB

However, despite setting this static time zone, I’m getting different dates produced by the element based on the browser’s time zone

Browser is in PST:

image947×290 4.78 KB

Browser in Japan time zone:

image1899×277 17.8 KB

Am I misinterpreting the function of the time zone setting on the element?

gf_wolfer · 2025-03-09T11:56:31.124Z

ramzizi:

Am I misinterpreting the function of the time zone setting on the element?

I do not think so. I think you are misinterpreting what the Debugger shows. In both your screenshots the Date/Times produced are actually the exact same moment in time.

The Debugger will always display a Date/Time back to you in your Browser’s time zone.

When you have it set to Japan time and see March 20 9pm, that is the exact same moment in time as March 20 5am Pacific. They are equal.
I wish Bubble would also show the UNIX time and a time zone in the debugger so this is more obvious as you are not the first to be confused about this.

Now it is up to you as the App Developer to display that Date/Time to the User in a way they expect. So if you have a Text element and display that March 20, 9pm time in Pacific time zone, it will display as March 20, 5am which I believe is what you are expecting