@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!