I finally had a chance to take a look at this new functionality over the weekend, and I’d like to share some thoughts. Let me preface my remarks by saying that I appreciate the work that went into this and hope my feedback is taken in a positive and constructive light as it’s intended.
I’ll cut straight to the chase… I find this approach:
-
Confusing
The value of the input is different based on whether it was manually or programmatically specified. -
Needlessly Complex
Additional fields now appear on inputs and pages, thereby adding unnecessary UI clutter. -
Inflexible
Can’t leverage the new functionality on a per-date-instance basis or with my own custom date/time input - i.e. the new functionality is limited to Bubble’s built-in inputs.
Honestly, the issue at hand relates to specific date/time values, so I don’t understand why this wasn’t implemented in a way that could be applied to any instance of a Bubble date type.
After all, there are really just two types of timezone-related operations, depending on whether the underlying timestamp changes or not. Since each Bubble date represents a specific moment / instant in time, one might wish to:
-
Interpret / format the date in a timezone of choice. This does not alter the underlying timestamp. The date still represents exactly the same moment in time, but the local time will be different. Bubble has always had this ability with the
formatted asoperation. (For example, displaying 9:00am America/New_York as 6:00am America/Los_Angeles.) -
Change the timezone while preserving the local time. This operation does change the underlying timestamp and results in the same local time but in a different timezone. (For example, changing 9:00am America/New_York to 9:00am America/Los_Angeles.) This is what the new features are about.
It seems to me the functionality described in this announcement could be implemented like…
…where selecting change timezone would allow the user to specify a from and to timezone, the former of which would default to the current user’s timezone. (Or possibly, just make the “from” timezone implicit and eliminate the need to specify it altogether.)
I think this approach is:
-
Simpler to use and understand - i.e. a single new item in the expression builder for date types.
-
More consistent with the way Bubble already works. Note that all of the “change” operators alter the underlying timestamp. Plus, the notion of an “implicit” (default) timezone being the current user’s timezone aligns with this recently announced change.
-
Much more flexible and powerful. One could use the new feature in their own custom date/time pickers and elsewhere.
And lastly, I want to point out that what I’m proposing is not theoretical. I built a plugin that uses the Luxon library to do exactly what I’ve described. It consists of a single action called “Change timezone to” and results in a new Bubble date with the same local time in a different timezone. It works great with my custom pure-Bubble time picker. It has also allowed me to use date types to handle time-only values as well as floating dates, such as birthdays. (In both cases, I just normalize the dates to UTC.)
I was hoping to be able to ditch my plugin and use native Bubble functionality, but the implementation announced in this thread falls short.
Any chance you’ll reconsider?
