Expression in .ics file email action not evaluating properly

Heads up. The email action for sending an invite, the .ics file requires a start time, and the start time dynamic expressions are not evaluating properly.

I did a simple test and put the same exact expression onto a page and it evaluated properly, however, the same expression on the backend workflow which has the action to send the email invite for the start time is not evaluating correctly.

CORRECT BELOW

INCORRECT IN LOGS AND EMAIL RECEIVED


Screen Shot 2024-03-08 at 3.49.02 PM

Its a Bugs Life :lady_beetle:

Hey Matt, have you ruled out the possibility that this is a time zone related issue?

I ask because the discrepancy depicted in the screenshots is seven hours, which happens to be the time zone offset for Thailand.

Hi Steve

That had crossed my mind and I did provide Bubble support with that context, however, I’m not 100% sure it is related or not as my client who is in Atlanta and brought the issue to my attention has the same time discrepancies on their side. However, this issue is related specifically to the use of database trigger changes.

Essentially we have a flow that kicks in when a booking is made, by the user which includes the email invitation getting sent out, and my client has stated to their knowledge no users are experiencing issues when the .ics files are delivered through this normal flow. The emails being sent are part of backend workflows that get triggered when a provider accepts and confirms the bookings date and time.

The time component is using an option set with attributes to hold onto the number hour and minute hour (ie: 10AM has hour number 10 and minute 0 while 10:30PM would have hour number 22 and minute 30). It is used to change the hour and minutes of the date confirmed by the provider. All of these values are saved to the database onto the booking data type, which the backend workflow uses as a parameter (ie: the booking data type is the parameter) and then uses the time option values to manipulate the date field’s time component for use in the .ics files start time date input.

When it is the provider that confirms the booking and this flow kicks off, as my client reported to me, there is no issues.

However, when implementing a feature for database trigger change via backend workflows to allow client to manually change a bookings date in the editor database, this kicks off the same flow, using the same backend workflows for sending the email with .ics file. It is when this flow is kicked off with the database trigger change that the issue occurs.

There may be an issue with how the date is evaluated via the backend workflows since they were initiated through a database trigger change, which may leverage the timezone of the user who manually changed the date in the editor database, but if that were the case, I thought my client would have seen time’s as 5 hours behind since Atlanta is 5 hours behind UTC, but even the reports my client provided I see the same 7 hour ahead difference…So, potentially, maybe Bubble is leveraging the timezone of the developer when building out that system, but I don’t know.

The problem though, is that no matter what is the cause, there is no easy solution as the ability to select which timezone the date should be using doesn’t exist…BUT, right now as I type I think I need to test the arbitrary date operator to see if that may help?

EDIT I just tried the arbitrary date feature and it won’t help since there is no ability to use a dynamic expression as the arbitrary date.

Need to know how Bubble is handling these things, so hopefully support can shed some light on that so I can find the way to account for whatever it is Bubble does on the backend to resolve for the issue if Bubble does not find the issue as a Bug but instead intended behavior; would need to know what the intended behavior is.

Check your time zone override controls under General —> Settings (scroll all the way to the bottom).

Thanks for the hint. I checked settings and saw no override controls, then went to the version and saw the app was on version 21, so updated to version 22 to get those timezone override controls.

I then set the database trigger change to have a static timezone of New York, which is same timezone as Atlanta where app is live.

When I run the system, now the time comes back as 9PM instead of 10AM when it is fed the data as below

Screen Shot 2024-03-09 at 11.30.26 PM

I am in GMT+7 timezone

Screen Shot 2024-03-09 at 11.35.49 PM

And the .ics file creation start time expression is below

Screen Shot 2024-03-09 at 11.36.38 PM

So if the confirmed date is April 12 at 11:59PM in GMT+7 that would be equal to April 12 at 11:59AM in Atlanta…the dynamic expression used to convert the date (which I assume due to the timezone override control with static timezone of America/New York - so same as Atlanta) that the date confirmed in the .ics file start time expression is still April 12 and then changing the hour number to 10 and minute number to 0 should result in a date of April 12 10:00AM Atlanta, but it is getting evaluated as April 12 9:00PM Atlanta.

This means now, it is 11 hours off instead of just 7 and I can’t make heads or tails of this issue because even if the .ics file display in email is for my timezone, that is still one hour off of what it should be since I am exactly 12 hours ahead of Atlanta at the moment.

Screen Shot 2024-03-09 at 11.42.04 PM

I opened the .ics file and added it to my calendar, which would be for my timezone and so it is showing as April 12 9PM, which if somebody in Atlanta opened it, that would be April 12 9AM, so it seems like it is an hour off for some reason.

I thought that maybe I had figured it out, that the issue of static timezone New York is wrong choice because of daylight savings…in Thailand we do not do daylight savings, so sometimes I am 12 hours ahead, and others I am 11 hours ahead…so I chose EST5EDT because I thought that was supposed to account for daylight savings as in my static choice should allow consistency through the year

Screen Shot 2024-03-09 at 11.51.16 PM

I understand the 5 hours west of UTC, United States DST rules to imply that daylight savings is accounted for and this timezone would always be 5 hours off UTC, but it apparently is the wrong choice.

So, now I am using the static choice of EST

AND DUN DUN DUNHHH

I Get to Test again tomorrow or the next day

Let’s see if this holds up or not.

Do you know offhand if the timezone of EST will take into account daylight savings or would you expect that once daylight savings hits, this will break again and be an hour off?

I found this article really helpful to understand differences between EST and EDT and which to choose and it seems like the logical choice from a coding/development stand point is ET…Why does Bubble not provide ET as a choice in the dropdown for static timezone values then??? They also don’t allow for, or at least recognize it (ie: ET) as a dynamic choice.

So, what are we supposed to do, put two different triggers together with conditionals to evaluate the current date to know if EST or EDT are currently in use?

Fingers crossed that Bubble just defaults EST to basically ET and accounts for daylight savings time and the tests I run in the next couple of days after things switch will still work.

I do know that there is an option to use timezone where change was triggered but still seems to me like there is some additional functionality needed to be built into the timezone override functions.

I think it works with the EST timezone setting. I’m getting the same values sent in (the correct values) today as I did a couple of days ago just before daylight savings time kicked in.

Thanks for the help on this as I was unaware that the timezone overrides were added back as a feature after they had been removed previously. Very glad to know those are back and can start making better use of them throughout apps.

1 Like

This topic was automatically closed after 14 days. New replies are no longer allowed.