Timezones can seem overwhelming. Its important to know what you are trying to do first. Think through it methodically. Simply saving everything in UTC isn’t a blanket catch-all.
Here are some useful examples:
CASE #1 - Two people in two timezones need to book a meeting together at the same time
IRL
If someone from New York scheduled a phone conference at 9AM (NY local time) and then someone from Los Angeles wanted to join that call, they’d need to call in at 6AM (LA local time) . This is the same point in time
In bubble (default behavior)
If a user in NYC puts 9AM today into a date picker and saves to the database. If another user in L.A. were to read that saved time it would appear as 6AM in their browser. The same point in time
CASE #2 - Someone in one timezone needs to work with times in another timezone
IRL
You call Delta Airlines customer service representative in Atlanta. You want to rebook your flight leaving from San Francisco from 9AM to 1PM. The representative sees the 1PM flight leaving from San Francisco on their screen and chooses it for the new booking.
To work well without confusion, the airline booking system needs to know what the timezone is for the airport of the departing flight. This way, the representative is working with the correct timezone.
In Bubble
Your app’s customer service team is in Atlanta (eastern time) and reads a user email from a customer asking them to rebook an appointment at their local dog washer (in San Francisco) from 9AM (PST) to 1PM (PST)
You’ll likely want your customer service agents in Atlanta to see what the current appointment time is in San Francisco and also reschedule the new appointment time in San Francisco local time (PST). You don’t want to use Atlanta local time (EST) when rescheduling this appointment because this would be confusing for the customer service agent. BTW, this confusing scenario is the default bubble behavior, so you’ll need to change it by adjusting the time as it is saved from the picker
So a solution might be that you store the timezone of each dog washer location in the bubble DB and then retrieve that timezone. Bubble’s built-in date picker always uses the browser’s timezone. That means if a person in Atlanta uses their browser to view the page and uses the built-in picker and chooses 1PM, then the time will be 10AM in San Francisco. You need to know the two timezones and perform an offset calculation of +3 hours so that you are saving in the correct point in time (1PM S.F. time and 4PM Atlanta)
Remember:
- You need to know the timezones of the location that you are booking
- You need to know if the the user who is working with time will be working in their local timezone or some other timezone.
- If working in another timezone, you need to take the time that is output from the datepicker (local time) and adjust it to your timezone of choice.
Note:
Your users may also travel. A user from San Francisco, may travel to NYC on vacation and go onto your website to book a dog washing appointment for 5PM In San Francisco when they get home. You need to make sure your site can handle these common issues.
If you are always working in a single timezone
In other words, all bookings, and appointments, etc are in the same timezone. You can conceivably work in UTC. There are some benefits to this as well.
- be very diligent to make sure all datepickers (outputting their local times) are have their dates/times adjusted properly to UTC prior to saving.
- tell bubble to use the UTC timezone in ALL text elements (the default is browser local time zone)
- use good UX and tell the user how the time is working. You can include a note about which timezone is being used. (“all times in PST”) .
Check out my other post on this which goes into more detail: Date and Time data structuring - #12 by jon2