How to manage timezones in Bubble.io (avoid common mistakes too)

Ever wondered why your Bubble app shows the wrong dates and times for half your users? Well, you're not alone. After 40 years in tech, from IBM's secret AIX team to building apps that serve thousands of users across the globe, I can tell you that time zone issues are one of the sneakiest bugs that'll kill your app's credibility. Stick around because in the next few minutes, I'm going to show you exactly how to handle time zones in Bubble like a pro. And trust me, once you nail this, you'll never second-guess your date logic again. Hey, I'm Dennis Lewis from ratio.dev. We're a boutique no-code agency that's helped everyone from scrappy two-person startups to growing Web3 companies build applications that actually work and scale. Here's the deal. Google does a pretty good job with dates and times most of the time, but the moment you have users and different time zones, or you start running backend workflows that don't have a user attached, things can get messy fast. And if you're not careful, you'll end up with appointment times that are off by hours or reports that show data from the wrong day. So today I'm walking you through the exact system we use to tame time zones in our Bubble apps. And at the end, I'll show you how to grab free access to our no-code resource center packed with vetted plugins, how-to videos, and frameworks just like this one. So how dates actually work in Bubble. What most people don't realize is that Bubble stores every date as a single number in the database, basically a Unix timestamp. It's not saving March 15th at 3:00 PM Eastern. It's saving something like 17105184. That's just milliseconds since January 1970. But here's when it gets interesting. When Bubble displays that date to a user, it automatically converts it to the user's local time zone based on their browser settings. So if you're in New York and I'm in Tokyo, we're both looking at the same database record, but we see different times on screen. And for most apps, this is perfect. You don't have to do anything. A user in California books an appointment for 2:00 PM. And a user in London sees it at 10:00 PM their time. Bubble handles the display. I don't want to call it a conversion because it's really the same date. It hasn't changed, but the display of that date automatically and everything's peachy until it isn't. Now, let me paint you a picture that's probably way too familiar if you're watching this video. You've got a backend workflow. Maybe it's sending reminder emails or it's calculating daily stats or it's, you know, reminding people to come back to their shopping cart if it's abandoned. And you schedule it to run at midnight. But midnight where? Here's the problem. Backend workflows that aren't triggered by a specific user default to UTC timezone. So if you're expecting your workflow to run at midnight Eastern, You're going to be off by 5 hours and your users wake up to emails that should have gone out the night before, or they don't get them until the middle of the next morning. It can be kind of frustrating because it's hard to understand what's going on because while it's mentioned in the Bubble documentation, it's not, you know, it's not like in giant letters that how this works. So, and maybe you've got users that travel a lot. So a sales rep books a demo for 3:00 PM while she's in New York, 2 weeks later, she's in San Francisco. Now our calendar shows 12:00 PM for that same demo. It can create confusion, missed meetings, angry customers. And here's the kicker: Bubble's native date pickers and filters always use the current user's actual current time zone. So if you're building reports or dashboards that pull date ranges, you can pretty easily show up showing data from the wrong day if you're not careful and you have people coming from that data coming in from different time zones. And I learned this the hard way. We built an app for a client with users across 4 continents and everything looked fine in testing because we were all in the same time zone. Then it launched and we started getting bug reports. My appointment is showing up on the wrong day. It looks so— it took us hours to figure out it was a time zone issue and another day to fix it properly. So, you know, these are kind of like the sort of those sneaky little things that happen in your applications. And and you're not really aware of where the problem's coming from until you really dig in. So how do we fix this? Bubble actually gives us some powerful tools. They're just not always obvious. So let me kind of walk you through the 4 big ones. First, you need to come into your application settings, go to general, and then scroll down here to the bottom. And you need to Enable time zone override controls. Okay. This by default will be clicked off. And then you can decide, do you want these available on daytime inputs, on, for on the page level or backend workflows? And then you can expose the option to, well, no, these are just, these are other here, but those are the main, these are the 3 main settings once you've enabled Time Zone Override controls. Okay. So until you do that, all of the other— these are the options that I'm going to show you aren't going to show up. But once that's on, you can pick a specific time zone for displaying dates, either at the element level or across a whole page. And this is useful if you're building something like a global events calendar where you want everyone to see the times in the event's local time zone, not their own. So for example, if you, you know, you have an event in London and you want customers or clients or users in California to see the calendar in the times in London, because if they're going to go to the event, then that's the time that, you know, if it's in person. So you can also store a fixed time zone for each user. So let's say you've got a marketplace app and sellers are always traveling. You don't want their home timezone to keep changing every time they log in from a new city. So how do you fix this? You store a timezone field on the user data type or any of, or in any table that you want. And so what that looks like is you would come here. I believe we have one in this workspace here and timezone, and it's just a text field, but, and so it's going to be something like America/New York or Europe/London. And there's a, this comes from the IANA time zone database format. So you can go, you know, you can find all of these in— there's in the Bubble documentation tells you where to go. You can do a search for that IANA time zones, and you'll find the list of those text descriptors. And that's what you're going to store here. And so here, I know that this workspace, its main time zone is always a specific one. And then you can also set the time zone for a specific page. So if I go to a page, I can come up here to the, to the page settings, and you will see here, time zone selection. And here by default will be user's current time zone, but I could pick a static choice and put one in for that page. So if this page was for a London event, then I could put it in there. What you can't do is on the page level, it can't be dynamic. It's going to be static for that page. So just keep that in mind, but we'll see some more options if you're, if you need it to be dynamic. So let's look at an example here. So let me show you how this works in practice. Let's say you're building a scheduling app and users book appointments and those appointments need to show up correctly no matter where the user is. So here's the setup. You store the appointments with a fixed time zone. So when a user books an appointment, you save the time, save the appointment's datetime field and timezone field like America/Chicago. And this locks in the true time of the appointment. But remember in the database, it's storing, still storing that numeric value. So you're always protected by that. Then you display the appointment in the user's current time zone, which is great, will happen normally if you don't change anything. So if they're in New York and they go to London, then they'll see it converted to London time, but run the reminders in the appointment's original time zone. So when you schedule at the backend workflow to send a reminder 1 hour before the appointment, you pass the stored time zone that you've dynamically stored in the, in the database as a parameter to that backend workflow. And it will send that reminder at the correct time in the correct time zone. So really important there. And now it works globally. So let's talk about some pitfalls to avoid. First of all, mistake number 1 is forgetting about datetime inputs. So Bubble's datetime input elements are kind of tricky. By default, they interpret dates in the user's time zone. So if you're not careful, a user in Tokyo might pick March 1st and end up saving February 28th in your database because of the offset. It's really going to store the correct one, but it may show up, it may display incorrectly. So, you know, that's where you might want to use a time zone override if that's really critical for your application. Mistake number 2: running reports without time zone context. So let's say you're building a daily sales report and you filter transactions where created date is greater than the current datetime rounded down to day. So it starts at the day. Simple. But if your user's in London and you're pulling data in UTC, you might be off by a whole day. So how do you fix that? Always be explicit about which time zone you're filtering in and test with users in different time zones before you launch. And number 3, not storing time zone data. Now this one's subtle. If you don't store the time zone when a user creates a record, you have no way to go back and figure out what time zone they were in when they made that entry. It's not always important because, you know, in the end you're still storing a numerical value for the date time, but it's good practice if you building an app that you know is going to be affecting users all over the world or in multiple time zones, and you can prevere, you can kind of, you kind of this feeling that this is going to be an issue for you, then just good practice is store the user's time zone either in their user profile or in, you know, if it's a critical datetime, put the, store it in a text field there just so that you can go back and check later. You may never use it. You may only, you know, want it every once in a while, but it's, it's good practice. Okay. So let's recap a bit. Time zone handling in Bubble. It doesn't have to be a nightmare. You just need to remember that the dates are stored as numbers and all of these things are affecting not the number, they're affecting how it's being displayed, how you're using, you know, you're, you're controlling when your workflows run, what time zone they're actually, you know, those workflows think they're in so that they run correctly. So remember that if you don't do this, they will run defaulting to UTC. Okay. Store a time zone field for users and records when it makes sense, or when, you know, or clients or, you know, organizations, whatever makes sense for your application. And then judiciously use the override controls to display the dates in the right time zone for your use case. Now, a lot of times, Sometimes Bubble's default behavior is fine, but, um, you know, in some cases you really do need this extra functionality. Okay. So if you want to get in deeper or you have more questions that about your Bubble application, I really recommend that you get our access to our no-code resource center. It's totally free. You just go to ratio.dev or use the link below and put in your name and your email and you'll get access to our vetted list of plugins that we know work and that they won't bog down your application. You know, a ton of how-to videos, podcast episodes, books and resources that will help you out. And we update it weekly. So it's an enormously useful resource for you. And like I said, it's totally free. So go grab that. And if you found this video helpful, do me a favor, give it a like, a thumbs up. And if you really feel like making me happy, then subscribe to our channel. I really appreciate that. And thanks for watching, and I'll see you in the next video.