[Breaking Change] Date Parsing on the Server

Announcements
1

Hello Everyone,

We’re about to introduce a breaking change that makes date parsing more consistently use client timezone (when known). This means that if you pass in text that does not contain timezone information (e.g. “06/08/2022 10:30pm”) we will parse that in the client timezone rather than defaulting to UTC on the server. This should only affect server-side date parsing (e.g. backend and API workflows), however the parsing code is shared by both client and server so there is a small potential for minor differences on the client as well.

If you wish to keep the old behavior, you can always make sure to include timezone information in any text you intend to parse (e.g. “06/08/2022 10:30 PM GMT”). Due to technical limitations of the libraries we use, in order for timezone information to be recognized by our parsing code you must do one of the following:

  • Use the ISO-8601 format
  • Use the RFC-2822 format
  • Include either GMT+NNNN, GMT-NNNN, (XXX) or (XX) somewhere in the date string you pass in (where NNNN is four digits, and XXX/XX are a two or three alphabetic characters of the same capitalization)
  • End your date string with XXX or XX (where XXX/XX are a two or three alphabetic characters of the same capitalization)

If your string does not contain timezone information through one of the above mechanisms, we will default to using the client timezone.

9 Likes
2

When will this breaking change go into production?

3

Just did!

It is worth mentioning just to be clear that this is released as a Bubble Version, so if your app is on BV 16 it should remain unaffected by this change!

4

Hey @alex.stanescu :wave:

What do you mean by ‘client’? Does it mean the person who owns the app? Or the users of the app?

5

In programming terms, "client’ typically refers to the device using the application, which is most often a user. I’m assuming that’s what he means.

6

If this is a “breaking” change, can you give some examples of how it might break an app? Since Bubble is mostly non-coders, this kind of post is more worrying than helpful. I’ll be honest, I don’t understand pretty much anything in your bullet points. It would be nice to have a bit more clarification (i.e., a few use-case examples) on what might cause an app to break with this update and whether most of us are probably OK or not.

7 Likes
7

That makes sense, just wondering what happens with webhooks and database triggers since there is no ‘user’ that initiates it. I’m trying to figure out if it takes on the location of the owner of the app. :blush:

3 Likes
8

Hey Sam! I’ve got a pretty good example since I’ll have to write up a patch for this in my next sprint.

In my project, I’ve got a system that creates a bunch of historical records at the end of each month. The historical records have a date field to allow users to view those records on a month-by-month basis. Since a search for these things is going to require a date and a time, we set all of the times to midnight so that all the developers on my team can easily write search constraints. For June, all of these records will have their date field populated by 06/01/2022 12:00:00 am.

Before this breaking change, my team knew that the backend workflows are going to default these times to UTC, so when I’m building a filter on the front end, I have to make sure that the search constraint I write is for midnight UTC. If I were to just plug in 06/01/2022 12:00:00 am for the constraint, none of June’s records would show up since I do not live in the UTC timezone. Since I’m in mountain time, I actually have to write the constraint as 05/31/2022 06:00:00 PM which is actually 06/01/2022 12:00:00 am UTC. (If all of our development team lived in one timezone, we would not have to do it like this, instead, we could write the constraint and just select the timezone we all live in. Technically we could also just pick one and we picked UTC.)

Now here’s why this is a breaking change. In my workflows that create these monthly records, we have the date field set to midnight UTC, but I simply wrote it as 05/31/2022 06:00:00 PM, the same as all of our search constraints on the front end. (Once again this is done to represent 06/01/2022 12:00:00 AM in UTC.)

Now, for most of my record creation process, I do not believe this will break anything since the whole process starts and ends on the backend. However, we do allow users to hit a button and create these records on their own. Since the user is doing this from the front end, their timezone is now going to be the timezone sent to the server instead of UTC. Previously our front-end record creation just sent the date as 06/01/2022 12:00:00 AM because we knew that the server would get this date, assume it was UTC, and we were good to go. This now means that we have to go in and specify that we want that to be UTC instead of the client’s timezone, otherwise some of our records will be 06/01/2022 12:00:00 AM and others will be 06/01/2022 06:00:00 AM or whatever offset from UTC the client’s timezone has.

Here’s why this is actually an excellent change and good news. If you’re building an app for people in your timezone this creates less headaches for you. If all of my users lived in Denver, CO, I can do less work to get all of the dates on records they create to be in the same timezone.

This change will be most problematic for anyone that wasn’t already formatting their dates and assuming the server would default them to UTC. I do think a good move from Bubble would be requiring you to specify a timezone when writing a workflow or a search constraint. This way there would never be any confusion.

4 Likes
9

I’m wondering the same. Hey @alex.stanescu! If a workflow starts in the backend, from another backend workflow, is the default timezone still UTC? To give you a bit more context, when I create data via the backend in this manner, usually the created by field will say “admin” or “deleted thing”. So it seems like the client in this case is “admin” which use to just use the UTC timezone.

10

Hey there! :wave:

@samnichols is correct! More precisely, we take the timezone from whatever browser initiated the first request to hit our servers. When you have a data trigger or backend workflow that is triggered from a backend workflow, that data trigger or backend workflow “inherits” the timezone of whatever triggered it. You can find more details on this forum post as well as details for what we do when an API workflow is triggered externally (e.g. not from Bubble)

11

@collinsbuckner1 gave a great example here of where changing the timezone things are parsed in could break an app.

One very important thing to clarify from his example is that this change only applies to when Bubble has to parse a date from some text. The three biggest examples of this are having to read a URL parameter, having to parse a API Connector response and having to read a date parameter from an (externally triggered) API workflow. So, in Collins’ example, if he has a Date Input that controls the creation of the historical records, then the Date Input itself will parse the date/time he types in on the client and his app will be unchanged. If on the other hand, Collins were to create those records by reading from some external API, then Collins would have to make sure the external API specified UTC.

I’ll be honest, I don’t understand pretty much anything in your bullet points.

The bullet points are a formal definition of what different ways of specifying the timezone in a string we are able to recognize. An example for each bullet point (note these are all the same point in time):

  • “2022-06-10T14:51:17-0500” (ISO-8601)
  • “Fri, 10 Jun 2022 14:51:17-0500” (RFC-2822)
  • “06/10/2022 2:51:17 PM GMT-0500” or “06/10/2022 2:51:17 PM (EST)” or “06/10/2022 2:51:17 PM (ET)” or “06/10/2022 2:51:17 PM GMT-0500 (EST)”
  • “06/10/2022 2:51:17 PM ET” or “06/10/2022 2:51:17 PM EST”

Hope that helps to clarify things!

1 Like
12

It should also be noted that we don’t expect any of this to affect most people’s apps. The spots where this would affect the way your app behaves are not extremely common, and most people won’t be relying on the old behavior. We released this as a Bubble Version out of an abundance of caution to allow anyone who may be affected the time to make sure their app is not affected!

2 Likes
13

hi,
ok might affect us. lets go through some workflows.

14

What I understand is that “timezone_string” parameters will not work anymore and we need to set the timezone into the date directly?
Will this accept something like America/Montreal, not just EST for example? (the main difference is that America/Montreal, Bubble was parsing with actual time and we don’t need to care about DST, while EST need to be formatted as EDT according to period of the year)

15

Hi Jici,

Quite the opposite - what this breaking change is doing is making sure that the timezone_string parameter is better respected.

To be perfectly clear; before if you passed in 06/10/2022 12:00 AM into a API workflow you would get 06/10/2022 12:00 AM UTC and now you’ll get 06/10/2022 12:00 AM in whatever timezone timezone_string refers to (or UTC if no timezone_string is provided.

3 Likes
16

Ok so the parameters timezone_string continue to work but will be applied correctly, that was not the case before with date (but was working with “Current date”)

17

When working with timezones in Bubble on a date object, we can only change the timezone and have that convert into text, and it is no longer a date object (from my understanding). I’m a bit confused as to how Bubble parses the text version of the date object after the timezone has been altered from the default of current users timezone to a timezone specified in a date object using the format as operator in order to change the timezone.

Are we actually able to pass into the database for a data field that is of type date a text that is a date string such as

  • “2022-06-10T14:51:17-0500” (ISO-8601)
  • “Fri, 10 Jun 2022 14:51:17-0500” (RFC-2822)
  • “06/10/2022 2:51:17 PM GMT-0500” or “06/10/2022 2:51:17 PM (EST)” or “06/10/2022 2:51:17 PM (ET)” or “06/10/2022 2:51:17 PM GMT-0500 (EST)”
  • “06/10/2022 2:51:17 PM ET” or “06/10/2022 2:51:17 PM EST”

Honestly, I am really looking forward to a feature that allows us to change the timezone of a date and have it still treated as a date object. That ultimately would alleviate a lot of issues with dates in Bubble in my opinion.

3 Likes
18

Ok so the parameters timezone_string continue to work but will be applied correctly, that was not the case before with date (but was working with “Current date”)

It was not the case when you passed in a text representation of a date and asked the server to turn it into a date object (e.g. parsing the text). (So basically what you said but I wanted to be clearer)

2 Likes
19

When working with timezones in Bubble on a date object, we can only change the timezone and have that convert into text, and it is no longer a date object (from my understanding).

Date objects are absolute timestamps and do not have a timezone associated with them, so when you convert it into text you have to specify what timezone you want to use (because the same absolute timestamp has many different textual representations depending on the timezone)

I’m a bit confused as to how Bubble parses the text version of the date object after the timezone has been altered from the default of current users timezone to a timezone specified in a date object using the format as operator in order to change the timezone.

We don’t (currently) provide an operator to turn text into a date object so I’m not sure what you mean by this? We also don’t have a timezone specified in the date object!

Are we actually able to pass into the database for a data field that is of type date a text that is a date string such as

Not if the database has type date. If it is of type text then yes

Honestly, I am really looking forward to a feature that allows us to change the timezone of a date and have it still treated as a date object. That ultimately would alleviate a lot of issues with dates in Bubble in my opinion.

We’re working on how to simplify working with dates in Bubble but it is important to remember that dates do not have a timezone attached to them, so a “change the timezone” operator would not actually do anything.

2 Likes
20

just want to doublecheck something.
we have 2 workflows that interact with another.

  1. a user sees a calendar on the frontend and then starts an api workflow at calendars selected time, change hours to 0, minutes to 0, we still have 00:00 of the users timezone right?

  2. we then create prompts at 3 minutes to 00:00 of the users timezone every day in a backend workflow. below a screenshot where we then change a date of this prompt. Here using: creation date change minutes to 0, change seconds to 0. Will this still refer to UTC as it is all in backend right?
    image

2 Likes