@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
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
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 
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
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.
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
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.
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.
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.
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:
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:
Browser in Japan time zone:
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
