Bubble stores all dates in UTC on the server and converts them to the user's local timezone for display. This tutorial explains how date handling works in Bubble, how to detect and store user timezones, how to display dates in a specific timezone, and how to avoid common timezone bugs in scheduling and search workflows.
Overview: Handling Time Zones in Bubble
Time zones are one of the trickiest parts of any web application. Bubble stores all dates in UTC on the server and automatically converts them to the user's browser timezone for display. This works well for simple apps, but gets complicated when you need to display dates in a fixed timezone, schedule events for specific regions, or search by date ranges. This tutorial covers all the edge cases.
Prerequisites
- A Bubble app that works with dates (events, scheduling, etc.)
- Basic understanding of how dates work in Bubble's Data tab
- Familiarity with the formatted as date operator
Step-by-step guide
Understand how Bubble stores and displays dates
Understand how Bubble stores and displays dates
Bubble stores every date field in UTC (Coordinated Universal Time) on the server. When a date is displayed in the editor or to a user, Bubble automatically converts it to the user's browser timezone. This means a date stored as 2026-03-28T15:00:00Z (3 PM UTC) will display as 11 AM for a user in New York (UTC-4) and 8 AM for a user in Los Angeles (UTC-7). You do not need to do any manual conversion for basic display — Bubble handles it.
Pro tip: When entering dates manually in the editor (e.g., default values), remember that Bubble interprets them in your browser's timezone and converts to UTC for storage.
Expected result: You understand that all dates are UTC on the server and auto-converted to local timezone on display.
Detect and store the user's timezone
Detect and store the user's timezone
Add a field called timezone (type: text) to your User Data Type. On your main page or in a reusable element loaded on every page, add a Page is loaded workflow. Use the Toolbox plugin's Run JavaScript action with the code: Intl.DateTimeFormat().resolvedOptions().timeZone. This returns a timezone string like America/New_York. Use the JavaScript to Bubble bridge to pass this value back and save it to Current User's timezone field. This stored timezone is useful for server-side operations.
1// Run JavaScript action (Toolbox plugin)2var tz = Intl.DateTimeFormat().resolvedOptions().timeZone;3// Output to bubble_fn_timezone(tz) to pass back to BubbleExpected result: The user's timezone string is saved in their User record for use in backend workflows and display logic.
Display dates in a fixed timezone
Display dates in a fixed timezone
If you need all users to see dates in a specific timezone (e.g., a conference in New York), use the formatted as operator on your date field with a custom format. Unfortunately, Bubble's built-in formatting always uses the viewer's timezone. To force a specific timezone, calculate the offset manually: store the event timezone offset (e.g., -4 for EDT) and add/subtract hours from the UTC date before displaying. Alternatively, use the Toolbox plugin's Run JavaScript with the toLocaleString method specifying the timezone.
Pro tip: For complex timezone requirements, consider a dedicated timezone plugin from the Bubble marketplace that provides proper IANA timezone conversion.
Expected result: Dates display in your specified timezone regardless of where the user is located.
Handle timezone issues in search constraints
Handle timezone issues in search constraints
When searching for records by date range (e.g., all events today), be aware that today means different things in different timezones. A search constraint like Created Date > today at midnight uses the user's local midnight, which converts to a different UTC time for each timezone. For server-side consistency, use explicit UTC boundaries: Current date/time +(hours): -Current date/time's hours to get midnight UTC, or store date-only fields as text (YYYY-MM-DD) when timezone-independent comparison is needed.
Expected result: Your date-based searches return consistent results regardless of the user's timezone.
Schedule events correctly across timezones
Schedule events correctly across timezones
When a user in Tokyo creates an event at 3 PM their time, Bubble stores it as 6 AM UTC. A user in London viewing that event will see it at the correct local equivalent. The key rule: always let Bubble handle the conversion by storing dates as-is from the user's input. Never manually add or subtract timezone offsets before saving. If you need to schedule a backend workflow for a specific local time, convert the desired time to UTC before passing it to Schedule API Workflow.
Expected result: Events are stored in UTC and display at the correct local time for every user.
Complete working example
1TIMEZONE HANDLING SUMMARY2=========================34DATA STRUCTURE:5 User Data Type additions:6 - timezone (text) — e.g., "America/New_York"78DETECT TIMEZONE (Page is loaded → Run JavaScript):9 Script: var tz = Intl.DateTimeFormat().resolvedOptions().timeZone;10 Output: bubble_fn_timezone(tz)11 Then: Make Changes to Current User → timezone = Result of JavaScript1213DISPLAY IN FIXED TIMEZONE (JavaScript approach):14 Script: 15 var date = new Date('[Dynamic date in ISO format]');16 var options = { 17 timeZone: 'America/New_York', 18 year: 'numeric', month: 'short', day: 'numeric',19 hour: '2-digit', minute: '2-digit'20 };21 var result = date.toLocaleString('en-US', options);22 bubble_fn_formatted_date(result);2324SEARCH BY DATE (timezone-safe approach):25 Instead of: Created Date > Current date/time (rounded to day)26 Use: Created Date > Current date/time +(hours): -offset27 Where offset = known UTC offset for the target timezone2829SCHEDULING BACKEND WORKFLOWS:30 Always pass UTC times to Schedule API Workflow31 Let the user select their local time32 Bubble auto-converts the input to UTC for storage33 Do NOT manually adjust — Bubble handles conversion3435KEY RULES:36 1. Bubble stores everything in UTC37 2. Display auto-converts to user's browser timezone38 3. Never manually add/subtract timezone offsets before saving39 4. Use Intl API to detect the user's timezone40 5. For fixed-timezone display, use JavaScript toLocaleStringCommon mistakes when workking with time zones in Bubble
Why it's a problem: Manually adding or subtracting timezone offsets before saving dates
How to avoid: Save dates exactly as the user enters them — Bubble handles the UTC conversion automatically
Why it's a problem: Assuming today means the same thing for all users in search constraints
How to avoid: Use explicit UTC time boundaries for server-side searches, or accept that date searches are timezone-relative
Why it's a problem: Displaying raw UTC dates without formatting
How to avoid: Always use the formatted as operator or rely on Bubble's auto-conversion, which adjusts to the user's browser timezone
Best practices
- Trust Bubble's built-in UTC storage and local timezone display for most use cases
- Store the user's timezone string in their profile for server-side operations
- Use the Intl.DateTimeFormat API via Run JavaScript to detect the browser timezone
- Never manually adjust timezone offsets before saving — let Bubble handle conversion
- For fixed-timezone display, use JavaScript's toLocaleString with the timeZone option
- Test your app with users in at least 3 different timezones before launching
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
I'm building a Bubble.io app with scheduling features and I need to handle timezones correctly. Users are in different countries. How does Bubble store dates, and how do I display events in the correct timezone for each user?
Set up timezone detection for my app. Save each user's timezone, and make sure all dates display correctly in their local time. Also help me fix a search workflow that returns wrong results because of timezone differences.
Frequently asked questions
Does Bubble automatically adjust for daylight saving time?
Yes. When Bubble converts stored UTC dates to the user's browser timezone, it uses the browser's timezone settings which include DST adjustments. However, if you manually hardcode an offset, DST will not be accounted for.
How do I display a date in a specific timezone for all users?
Use the Toolbox plugin's Run JavaScript action with JavaScript's toLocaleString method, passing the timeZone option set to the desired IANA timezone (e.g., America/New_York). This displays the date in that timezone regardless of the viewer's location.
Should I store dates as text to avoid timezone issues?
Only as a last resort for date-only fields where time does not matter (e.g., birthdays). For any date with a time component, use Bubble's native date field type and let Bubble handle UTC conversion.
Why do my date searches return unexpected results?
Search constraints on dates are evaluated in UTC on the server. If your constraint references a user-local time like today, the UTC equivalent may span a different calendar day depending on the timezone. Use explicit UTC boundaries for consistent results.
Can I let users choose their preferred timezone?
Yes. Create a dropdown with timezone options (populated from an Option Set of common IANA timezones) and save the selection to the User. Use that value in display logic. RapidDev can help build timezone-aware scheduling systems for global apps.
What timezone does the Bubble editor use?
The Bubble editor displays dates in your browser's timezone. When you enter a date in the editor (e.g., a default value), it is interpreted in your local timezone and stored as UTC.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation