I’ve read that storing all dates as UTC in Bubble is the best approach so that they can be displayed later on in a different time zone as a text.
What steps are required to store a date as UTC in Bubble?
I can’t understand why we can’t simply ‘convert to UTC’ inside of Bubble when a date is picked by a user or an API endpoint is hit with a date.
All dates are stored in UTC in bubble.
You then choose how you want to display that date on the front end of your app.
Dates are definitely one of the more confusing things to work with in bubble.
I don’t think this is the case, or maybe I’m not understanding.
In EST, a user saves a date, and reads it from their browser and it’s correct.
Another user (also in EST) browse the website and reads the date and it reads correct for them too.
Then a user from PST comes along, and browse the date, and it’s entirely different.
To me, it seems that the original user’s timezone (based on the browser) is setting the timezone of which the date is originally inputted, as both browsers in EST timezone are able to read the output of the saved date the same on the front end.
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:
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.
Check out my other post on this which goes into more detail: Date and Time data structuring - #12 by jon2
Part of what I’m trying to figure out, is what’s happening when I’m sending a date to the bubble api…
When I send a date from a date picker on a mobile device, here’s what happens, and I’m absolutely lost:
A few minutes ago, I created this output from a mobile device in EST timezone:
Current device time:
Aug 15, 2019 12:19 am
1565828380440
Using a date picker, I selected the following date: August 15th 06:30 am
Aug 15, 2019 10:30 am
1565865000000
Then a few minutes later, I changed my mobile device to PST timezone:
Current time:
Aug 15, 2019 12:23 am
1565828582674
Using a date picker, I selected the following date: August 15th 06:30 am
Date of travel:
Aug 15, 2019 1:30 pm
1565875800000
I am trying to preserve the date that was inputted by the user in the date picker…
I will then need to add minutes to the date to then calculate an arrival date/time (which is also going to be in the destination time zone)
Expression to display/save the offset time:
Datepicker’s value +hours [offset hours]
Where ‘offset hours’ is the numeric value of your timezone offset
This topic was automatically closed after 70 days. New replies are no longer allowed.
