I’ve got the above action in a trigger event (below).
but if I run it after around 1pm EST (my local time zone and the users local time zone) when it “rounds down to day” and adds 9, it’s 9:00am THE NEXT DAY. I ran this on Sept 25 and got this…
But when I put the exact same expression in a text box on the UI, it correctly sets the time as 9am on the 25th, not 26th,
So it only seems to screw up “Round down to day” on calls to Set Recurring… specifically…
I did check the timezone on the "Round down to " box and it is set to the local timezone too.
Has anyone else experienced this?
I am a little confused, you want the start date scheduled back in time??
Today is 9/25, so if you scheduled it for 9am and its 1pm, it doesn’t have a time machine to do that
And that’s just the start date, so it’s gonna happen tomorrow just like you asked it and will repeat daily anyways
No, the 9 was just to make it simple. In reality, I’m setting it to about a half hour into the future from whatever time it is when I start the test. So at 8:15pm i was setting it for 8:30pm.
where “user now’s s_remainder_time hours” is 20.5.
Oh I see. Did you try this from the Bubble docs?
If it still doesn’t work you could probably just switch this to the standard “Schedule an API Workflow” and schedule it for the time you want, then have the next one schedule it again in an infinite loop (with some kind of condition to break it if need be)
Also I think you’re gonna hit a wall real quick, because it says in that warning only 1 recurring event per thing, but I think they mean Datatype, so settings up another recurring event won’t even work
I could be wrong though if you’ve tested it and can confirm.
The “Time Zone Selection” and the “Dynamic Time Zone” settings in my original screen caps is my use of the settable timezone overrides. They’re working fine for everything EXCEPT scheduling. In fact, I use the same expression in the same workflow to write to a logging table and the expression is resolving to September 26 at 10:00pm but the scheduler has it as September 27, at 10:00pm.
It’s one per “thing”, which is bubble’s crazy word for “record”. In this case, that’s per-user. I’ve successfully tested it creating multiple schedule entries, each for different users.
Ok… after much banging I figured out what was happening and it’s working as documented, although arguably not as it should (IMNSHO). For anyone searching later, the problem wasn’t in the rounding.
In my case, I have notifications going to users at a time of day they can choose. They can also choose email and/or SMS notifications. So they have a few options from which to choose:
(forgive the ugly UI alignment, I’m in the “function over form” stage of development)
Then I have a database trigger looking for any change to any of those fields and pushing a request for the thing (ie. user) to the scheduler. But if you push an event to the scheduler which is identical to the existing record (which is what happens when someone has, for instance, email and sms selected but then turns off only one of those) it doesn’t decide to keep it, it decides to push it one interval forward (a day, in my case). This is documented here:
There were 4 possible solutions that came to mind.
- Use a trigger to detect a “substantive change” to the notification settings, save it to the user record, then have a trigger on changes to “substantive_change” that would clear and/or resubmit the recurring event for the user
- Use a trigger to determine “next message date” and save it to the user record. Then have a single API workflow scheduled to run at the lowest offered granularity (every 30minutes, in my case) that finds all users set to receive a notification at or before that time, execute the email/SMS, and recalculate the “next message date” for that user based on their settings. (the approach floated generally by @tylerboodman above)
- Whenever the user changes any of the attributes above, have the database trigger clear the schedule for that thing(user) before setting the recurring event for them, even if what it’s replacing it with is exactly what it was in the first place.
- (which just occurred to me as wrote this post) Combine options 1,2, and 3… have a trigger always calculating “next message date” as described in number 2, trigger on a change from the old “next message date” to a new “next message date” (essentially indicating a possibly substantive change like in option 1), and then push the new schedule for the thing(user) as in option 3. This would slightly reduce the impact on the schedule by reducing clear-recurring/set-recurring cycles if they sit there ticking one of the boxes on and off on a single day.
My ideal #1 would be for the scheduler to not check only that the new date is AFTER the existing scheduled date and to push it by a whole interval if it isn’t, but to check if it’s AFTER or EQUAL TO the existing scheduled date… so it would leave it alone if I were trying to set the time from 9/26/23 at 10am to 9/26/23 at 10am.
My ideal #2 would have been to be able to query the schedule to see if any existed for the user and if what I wanted to write was going to be a change or not, and then only apply it if it would be a change. However, I was unable to find a way to query the schedule yet.
As it is, I’ve opted for #3 above as I expect it will have the lowest complexity and lowest workload impact (given people would likely change their notification settings infrequently). I may have to revisit it as my app gets more complicated if I need more scheduled tasks for users… then I’d likely fall back to option #2 for the new things, even though that would require a frequent full-table search on every execution.
I hope this helps
