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:
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:
The value of the input is different based on whether it was manually or programmatically specified.
Additional fields now appear on inputs and pages, thereby adding unnecessary UI clutter.
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…
change timezone would allow the user to specify a
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?
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 .
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!
Thanks for the consideration @grace.hong !
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.
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”.)
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!
Sounds great to me. Hit me up any time.
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?
It should be in the format of any of the timezones listed when you select “Static choice” for “Time zone selection” - so either
EST should work!