So here's what I'm assuming:
- Your date attributed is localized
- Users who are entering a date are in a London timezone
- The time is not relevant, users only select a date

Here's what I guess is happening, see my image:
- Users entering a date after the BST are selecting a date (yellow)
- This localized date is saved as UTC time (an hour earlier)
- Your datetime variables are made and the booking pops up as the same date

You should consider:
- If time is not relevant, don't localize the date attributed
- Use a different retrieve to determine if an sms should be sent
- You are now retrieving all bookings (not neccesary)
- You are now creating a date variable each iteration (not neccesary)
- You are deciding each iteration if an sms should be sent (not neccesary)

Solution:
- Create a date variable, before the retrieve, with [%EndOfCurrentDay%]. Call it $thresholdStart
- Create a date variable before the retrieve with addDays($thresholdStart, +1). Call it $thesholdEnd
- Retrieve Bookings with Bookingdate > $thresholdStart and Bookingdate < $thresholdStart
- You now have all the Bookings for the next day and can safely send your sms without further checks

There seems to be nothing wrong with your scheduled event, but problably with the xpath retrieve of scheduled bookings?

https://modelshare.mendix.com/models/6d60ccb4-c643-4acf-9206-e05275b4f978/su-b-bulky-waste-send-booking-reminder

Here is the microflow that is called on the scheduled event.

Many Thanks,
Christina

I would suspect this: trimToDaysUTC([%BeginOfCurrentDay%])

You are using the BeginOfCurrentDay in local time but trimming it in UTC.

You can either use trimToDays() or [%BeginOfCurrentDayUTC%]