I used Date. The other options didn’t seem applicable. In the Microsoft world, there’s a difference between date and datetime so just specifying date seems odd to me.
Thanks for the screenshot, Treb. I suspect your issue is due to this recent breaking change. Since the dateTime string itself contains no timezone information, Bubble uses the user’s timezone. (Bubble previously assumed UTC, but now it doesn’t.)
Yep, that’s the issue. Microsoft Graph returns dates like this:
“dateTime”: “2022-08-07T00:00:00.0000000”,
“timeZone”: “UTC”
ISO8601 allows unspecified dates to be treated as local time or UTC.
I should be able to add a Z to the end of the datetime to force treatment as UTC per the standard, but I’m not sure how I can do that to a Date field.
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?
9 Likes
This will be way better @sudsy 
Thanks for the suggestion!
I always suffered with this issue, as some of my apps are “Booking Apps”. Every time I send and manipulate any Date in backend, Bubble changes the timezone and the result is always wrong. What I do is I to store the user’s timezone as a variable and send it to backend. So after I manipulate the Date, I can correct the adjustments made by Bubble. It is a pain in the ***.
It will be nice to have a simple and direct way to change the date between timezones. And the way you proposed is all I always wanted 
.
Change timezone from user’s timezone to Apps timezone. Simple like this 
.
2 Likes
@sudsy @rpetribu Thank you so much for the thorough feedback! We’ll keep those ideas in mind as we consider how we might refine this feature set to be clearer and simpler for users.
You bring up a good point about how to simplify our approach. From a technical standpoint, this would require a new data type. Today, we store date-times without associating them with any timezone once they’re in our database. To be concrete, say we have 8/4/2022 10:00 AM ET as date-time X. When we save date-time X, date-time X can be represented an infinite number of ways: 8/4/2022 10:00 AM ET, 8/4/2022 7:00 AM PT, and any other number of date-times in different timezones.
Implementing this method of converting a date from one timezone to another within an expression would require a new data type that has two distinct parts – a timestamp (“8/4/2022 10:00 AM”) and a timezone (ET). It requires a good amount of engineering effort since we’re working with dates in JS. Nonetheless, providing a more uniform method to parse date-times in a particular timezone is certainly well worth more investigation.
Thanks for your thoughts, and feel free to share anything else that might be helpful!
4 Likes
Of course, @grace.hong. I understand it’s a UNIX timestamp. What I’m proposing would NOT require a new data type or a change to the way Bubble stores dates. I don’t understand what it is about my description that makes you think otherwise.
No, it absolutely would NOT - not the way I’m envisioning and have described it. Perhaps you missed the part about allowing the user to specify the from and to timezones with the implicit (default) from timezone being the current user’s timezone. Again, I’ve already implemented this functionality in a plugin. It’s quite straightforward.
The onus would be entirely on the the Bubble dev to track/store timezones if/as needed.
Please let me know where I need to elaborate, because I think you’re making it out to be more complicated than it is. I’d be happy to clarify any points and/or describe the behavior in more detail.
The main issue is that the feature apply to text only or something like that. A few week ago we was trying to use it me and @johnny and face this issue because the “date” was already parsed… Anything you could do doens’t affect the date saved as a date. Bubble will continue to use the same date timestamp. To fix that, we needed to send the request in a backend WF… using API Connector! And the settings in the backend WF was applied correctly because it’s was sent as a text.
1 Like
Yes, I’ve already acknowledged and described that. Please re-read the 2 bullet points following the paragraph starting with…
As I’ve said, Bubble has always had the ability to “interpret / format” a given date in any timezone. That does not change the underlying timestamp.
What I’m advocating for is a way to CHANGE an instance of a date type to a different moment in time (alter the underlying timestamp) by “converting” that date to the same year, month, date, hour, minute, and second but in a different timezone. Such an operation will alter the UNIX timestamp.
For instance, 04-AUG-2022 4:30 PM in New York is not the same moment in time as 04-AUG-2022 4:30 PM in Los Angeles. (Some refer to this as “parallel dates”.)
EDIT
To perform such a Change timezone to operation, all that’s needed is a UNIX timestamp, the from timezone, and the to timezone. I’ve described how that could be implemented. Please let me know what’s unclear.
Gotcha, thank you for the additional explanation. Yes, your recommendation would be feasible with our existing date-time type (which uses UNIX timestamps as you mentioned), and apologies for misunderstanding you earlier!
I’ll discuss with my team a bit more because we’d want to be conscious about building this feature in a way that doesn’t heavily increase the learning curve for our new users. Once we have some additional ideas or prototypes, I would love to reach back out and iterate on your feedback!
2 Likes
Sounds great to me. Hit me up any time.
1 Like
Hello @grace.hong
In what format should we transmit the time zone in the backend workflow?
Like America/NewYork, or EST, or else?
Do I have to download the entire TZ file from Time Zone Database to connect the dot? 
John
It should be in the format of any of the timezones listed when you select “Static choice” for “Time zone selection” - so either America/New_York or EST should work!
2 Likes
Hello @grace.hong
In Backend Workflows only static selection works
not dynamic like “America/New_York” or “EST”.
Do I have to use a specific format instead of using “text” ?
Dynamic selection in “America/New_York” or “EST” formats is not working for me either. Did you find a solution?
1 Like
Using now “EST5EDT” (and others) instead of EST.
1 Like
I’d really enjoy the option to display dates/times in my DB view in different time zones. I’m trying to standardize everything in my app on UTC, but it’s rendering it in my local time zone, which causes unnecessary confusion.
Ditto on the server scheduler.
1 Like
Hey all,
After speaking to new and old users through interviews, we’re deciding to fully release the first experimental feature (“Overriding timezones for date-time inputs”) which provides the capability to override timezones for date-time inputs and deprecate the second experimental feature (“Overriding timezones more broadly”). For apps that have ever toggled on/off the second experimental feature, the feature will remain visible, but it will have a “deprecated” status next to it. This second experimental feature will be removed in our next Bubble version, to which users can manually upgrade so they have full control over their transition.
Through our interviews, we found that users wanted to clearly understand what timezone is being used (before and after overriding) and what timestamp is being created when they’d like to save a date-time using a different timezone for parsing. While the existing design does add a new field to input elements, users found that this field offers more transparency, compared with an operator on an expression or a timezone for a page. Using an operator on a date-time also doesn’t solve the problem of users wanting to parse entire expressions in a particular timezone; in the current design, it’d have to be applied on every date-time (or subsequent operation) or set at the page level to maintain the interpretation and could more easily result in accidental inconsistencies. We’re still cognizant that users face challenges in designating the overriding timezones for date-times entered through non-inputs (API calls, operations, etc.), so we’ll still be brainstorming better designs for a safer feature while deprecating this initial version.
I will update this post when we have the new Bubble version in which the first feature will be released and the second feature will be removed.
5 Likes
Hi @grace.hong Just to be sure, this will stay? I’m not sure if I see the second feature you talk about.
