With our application, we have always entered event bookings, with specific start and end times, based on the time at the customers location, and it has never created a problem.
Recently, daylight savings time kicked in and we live near a state border. So when it’s 4pm for admin users at our office, it’s 5pm for some customers south of the border.
The issue that’s surfaced is that for some unknown reasons, even though we expect and want to continuing entering times based on the location of the user, the bubble system only accepts the time based on the admin users location.
With lots of customer support, it becomes impossible to keep track (ie. each person remembering that if they say 4pm in location X, admin user has to enter as 3pm) and it creates annoyed users, as times automatically changed (forward 1 hour) in their apps, when they aren’t meant to. They’re meant to stay the same.
Bubble have said there is zero timeline for fixing this. Does anyone know a fix / solution that’s workable for longer term? We want the time entered by anyone for an event booking at a location, to be exactly that time at that location?
(ie. it should never move / forward or back when daylight savings finishes either, and it should never be based on time at admins location / and admin should only see times in our systems also that reflect the booking times at the event locations.
I suspect the solution is to collect the time along with the timezone directly from the user and then also publish your events with the time and a specific time zone as well. This way, there’s no risk of the timezone being off inadvertently.
This is entirely do-able in Bubble and, in fact, we’ve done something very similar ourselves. That said, it’s a bit of a pain to set-up simply because working with timezones is often more complex than it should be.
We had set-up our own API endpoint to convert times from specific times and timezones to a a time value Bubble understands and then back again to a specific time and timezone. I think Gaby created something similar and published it as a plugin or similar. Either way, there are numerous tools for these calculations with Bubble now so it should be straightforward enough.
I should also mention, there’s the added complexity that sometimes users don’t read timezones (and just assume all times are in their own timezone) so this won’t be a foolproof solution for you, from a UX point of view.
Another solution that may be worth looking into is whether there’s another service that can grab the timezone from a user’s location (or their computer) and simply use that to adjust the times. This way, you could still display times back to users in their timezone. Just a thought.
This is how date/times work in JavaScript and, hence, Bubble. When your admin users enter time/date info, they can ONLY do that for their browser’s location (which may itself not be correct).
If you are entering date/times with respect to — or on behalf of — some other (known) location, you must transform the dates to that location’s local time (on the date in question — keep in mind that a date at some future or past time is of course NOT guaranteed to be in the same “timezone” — by which we mean offset from UTC— as it is “now”).
This can be done with moment.js and moment-timezone libraries, but it isn’t necessarily easy.
For a brief introduction, see:
I’m sure what Bubble support told you was not that there’s “no timeline” for “a fix” for this. The truth is this:
There’s nothing broken — this is just the nature of date/times and time zones and Timezone adjustments (e.g., DST).
What you need to do is establish locations for the things you’re setting times for. So if the location of your customer’s thing is 10 feet away from you, but that puts it in a different Timezone from your reps, you can transform the date/time entries to be accurate in the target locale’s local time.
This is a pain, but it can be done. (Have users input geographic addresses, by which you can then get Timezone IDs, which moment-timezone can then transform into local times at a given date/time in some other Timezone ID.) You can retrieve the Timezone ID from a geographic location.
NOTE: A Timezone ID never changes, e.g., “America/Los Angeles” is always “America/Los Angeles” (it’s what you might call a “locale”), but the Timezone (which is NOT a locale, but an agreed-upon convention for local time) that is in effect on a certain date such as “Pacific Daylight Time” vs “Pacific Standard Time”, most definitely does.)
A complete discussion of this is WAY beyond what one can convey in a forum post, but this should get you started.
There would be easier solutions to this common problem, but there’s not yet a way to build out complete moment-timezone support on the Bubble server side (even though I believe Bubble already relies on this very popular and helpful library to perform certain date/time operations).
Tl;dr: I feel your pain. And, if you want to do Timezone-aware date/time operations, you can. It just cannot be done in vanilla Bubble and requires some scripting, loading of external libraries, and forethought. It’s not simple, as I’ve tickled several Bubble bugs in my pursuit of Timezone-aware date/time math.
But you can get it to work. My seemingly basic vacation rental availability calendars actually show date/times in the rental’s local Timezone transformed into the viewer/consumer’s local time.
Hey Keith [sridharan.s - awesome insight, thanks for this.
After digesting everything, our team is wondering…if we always intend to only ever display the time based on the time at the event location… (and we’ll display a little label showing which state the event is in…
and that’s the time both the buyers and sellers will see (even if they live in different states - that’s how people think where we live)…
… What’s the risk of us changing times to a text numeric format ie. 12:30pm (by using things like a dropdown selector) ? Seems that will avoid javascript and browser issues?
