[Breaking Change] Date Parsing on the Server

Example on how this affect Backend WF when using an external call with timezone_string parameters.
Request (In one test, I use UTC for timezone_string):
Capture d’écran 2022-06-10 164811

Results:

Before, Bubble applied the timezonestring parameters only to Current date. Now it applied to date correctly. Also, “text” version doesn’t change. The value from the request is kept.

3 Likes

Thanks Alex. After this read, I’m 99% certain it’s not the case, as the change appears to only be textual date parsing, but just need to make ice-cold darn sure that this in no way affects interpretations of timestamps when pushing/pulling UNIX epoch ms values, and those values are indeed still grounded to UTC interpretations at all times, both as-read by Bubble from API’s and as-generated by Bubble in client sessions. Can you please confirm this is indeed the 99% likely case?

Thanks for the example! That’s helpful. :slight_smile:

  1. Yes

  2. Yes - we’re working on ways to better handle selecting what timezone operations like “change minutes to” execute in. (BTW the creation date does not have a timezone associated with it as it is a date object)

3 Likes

Yes. 100% - we store Dates as UNIX epoch ms values (which by definition are grounded in UTC) and converting to/from the numeric value is always a No-Op

3 Likes

thanks for your fast answer Alex.

Thank you for the clarification @alex.stanescu. I should have noted that in my example all of the data creation is being done via the bulk endpoint in the data API which is why we will have to make some changes. Once again though this is a welcome change over here. I was able to explain to leadership why we have to make a bit of an urgent update next sprint, but that the value in saved dev time was well worth the hassle. They seemed to agree. Nice work! Hopefully one day I’m a talented enough programmer to build what is effectively a programming language.

I was referring to the format as operator on a date object which converts it to a text object and is currently the only way to change a date objects timezone from UTC to any other timezone. My confusion was thinking that Bubble parsing the text object representing date/time was somehow going to affect the way a user sees it, but understand this is all about how we can change a date object to a text object to show the text representation in a different timezone other than UTC.

I’m more looking forward to it, not for the purpose of making it so when it is stored in the database it is not in the UTC timezone, but for using it in dynamic expressions to dynamically change the timezone of the date object used in the dynamic expression, so we can continue to work with it as a date object rather than it being a text object. Currently I have to run some javascript to change the timezone of the date object to change the timezone and continue to use it as a date object. It would be nice to just have an operator that does this so could do it ‘inline’ of our dynamic expressions. Think about scheduling a backend workflow at different times according to a dynamic timezone rather than the current users timezone, or changing a date object to be the same date but in a different timezone.

I understand everything about date objects use the UTC timezone when stored and that is fine, but would be great to have an operator to change the date object timezone when working with that date object in dynamic expressions, even though it would still be saved to the DB as UTC.

1 Like

Hi @alex.stanescu , just to check with you… cos we actually ask our client to put in GMT +8 timezone(as our client is from different countries and we will need to standardise), and then the time will trigger the api workflow. But after your update, how do I set it so that the clients will have to put in GMT +8 timezone and for our backend to see the exact time that they put?

Hi @alex.stanescu , are you also adhering to the ISO 8601 standard where if the date value ends with a Z, it should be treated as UTC?

1 Like

General Question: When I upgrade to a newer Bubble version, does it only apply to the testing version of my app until we deploy to live? I’ve been hesitant to upgrade because I’m having trouble finding an answer to this question, and I would normally always test things in testing before pushing to live before using Bubble. Just want to make sure testing v17 won’t make the live app v17 until we deploy. Thanks in advance!

Hey @samnichols :wave:

This should answer your question. :blush:

https://manual.bubble.io/core-resources/application-settings/versions#available-bubble-engine-versions-and-current-version

1 Like

@J805 you rock! Thank you!

1 Like

Working on something right now that uses the “change hours to” and it seems like it’s using the Client’s timezone [PST for me] to do the operation, so if I trigger the workflow VS if my partner triggers the workflow from NYC then I get 2 different times.

Any thoughts on this behavior?

The expected result is to set the time of the timestamp to 12:00pm in NY. Currently, I changed the timestamp of Oct 31st 9:00pm in PDT ( which is Nov 1st 12:00am EDT) by using “change hours to 12” and the result is Nov 1st 3:00pm EDT ?