You should store and display all dates/times in a single timezone (most logically UTC). The User’s local timezone is irrelevant here - unless its not of course, in which case store it as both (or convert it from UTC to local as and when needed, using Luxon).
either store as UTC or allow the user to select the desired timezone
if storing as utc you’ll also need to ensure all backend workflows process in UTC - you can turn this on in the settings and then toggle it on each API workflow
I’m actually already using TopCal plugin. The issue is that to the user, it appears that the date is correct, but when the user’s timezone (if in a far off location like Asia) and Bubble’s time zones are apart enough, when the date is saved to the database it records it as a day off.
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.
Hey @ramzizi, this is fully doable with TopCal but as you have noticed there are a couple things to do if you want Dates/Times to always be showing in the timezone of the location of the hospital, there are two main things you must do.
Always set the time zone id in TopCal elements to be the time zone id of the hospital (looks like you are)
For text elements always use the :formatted as for Date/Times and be sure to set the time zone id to the hospital’s
As an example this homepage, screenshot below, lets you set availability in a specific time zone, and then displays the times back in your current browser’s time zone. To change it to the function how you want with showing in the target time zone, you would make sure the Calendar and Times (highlighted) are the target time zone instead of current users.
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.
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:
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?
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
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.
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.
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:
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
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).
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.
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.
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.
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
I just released the free template that uses my plugin.
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.
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.
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
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.
