Time zone headaches

adamhholmes · 2025-02-18T12:55:16.580Z

My goal is to have the app be independent of time zones. If a shift at a hospital starts on 8/15 at 8AM, that’s what it needs to say for every user regardless of where they are.

I think I’ve managed a partial fix now by setting the time zone to the hospital’s address when the hospital posts a shift. This now lists the shift date correctly, but I still fear users will still see the wrong shift dates somehow.

Using a separate timezone for each Hospital is fine… as long as you don’t need to cross-reference shifts from one hospital to another (across different timezones) as that will lead to date mismatches.

(for example, if doing this for hotel bookings, where you need to check available dates on hotels in different timezones, using the Hotel timezone will not work - for that you should use UTC).

But if you don’t need to do that, and each Hospital’s shifts are completely isolated from any other hospital’s then using the Hospital timezone is fine.

Just don’t use the User’s timezone.

ramzizi · 2025-02-19T05:53:23.812Z

Hi @gf_wolfer

Thanks for the advice. I’ve now fixed the issue of at least showing the right date when a hospital posts a shift, by making sure that the date is set to the hospital’s time zone when the shift is created.

I’m running into another issue now. On the home page for both doctors and hospitals I have a calendar which displays confirmed bookings using your GetAvailableTimeSlots element like this:

image1144×1438 158 KB

image1144×1438 143 KB

The bookings are not showing if the user is in a far off time zone. How would you suggest addressing that? I do have a user that’s creating bookings at hospitals in America and she lives in England.

In this case though she could be booking multiple different hospitals across different time zones.

I realize it’s getting complicated now - do you book private sessions to help me through this?

gf_wolfer · 2025-02-19T09:05:26.980Z

The bookings are not showing - where exactly are they not showing that they should be?

A couple ideas

Were they made when the calendar / time zones were not lining up as expected? Old data could be a likely reason since the recent change from this thread
If they are not showing based on that second screenshot, I am curious if the BookedDate is the culprit is it a Date or Text field in the database?. If it is a Date, is it the start time of the Booking? If yes, this will not line up exactly with a Start Date of a say a Calendar’s cell which is usually 12am. You would want to filter based on the entirety of that Day in a calendar, not a specific point in time

ramzizi:

do you book private sessions

My time is limited so not usually but I’ll message you directly.

PS - any quality Bubblers that see this that want the odd paid job helping with well defined problems with TopCal and scheduling shoot me a message.

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.