I have a booking site and I now may need to switch all my time zones to UTC. However, the problem is that previous bookings made with the old time zone settings won’t display properly due to daylight savings. I have shift dates displayed on my calendars based on the date, which rounds down to 12am. So a date that was booked as March 13 12AM is not showing up because in UTC it is March 12 11PM.
There’s a function to round down to nearest date, which won’t work in my case. Is there a way to have the date rounded to the closest midnight date?
you’d need to change the page and workflows to run in utc if the date input is utc and you want to display/process the dates in UTC rather than the users timezone
you can use “round to date” but if you enter the date via a date input it will already be midnight
I’ve tried switching to UTC, it’s not an easy fix in my case. If I didn’t have pre-existing bookings I would be fine, but unfortunately I’m an idiot and didn’t think about time zones when I started my app
OK I’m thinking the solution here is going to involve Javascript. Can anyone help me out? I have the toolbox plugin but have zero experience with this sort of thing.
I’m trying to return midnight dates only. My idea would be to grab the list of dates produced by Air Date/Time Picker (let’s say they are April 14 11pm, April 21 12am). The script would move each date forward one hour, then round down to nearest date.
You’ll really need to use Luxon for this (check out the Luxon docs - or there might be a public Bubble Luxon available) - and you need to know the original timezones the Dates were defined in.
If you know (i.e . you have stored in the Database) the original Timezones used for defining each Date, it’s simple…
You can just create a new Date object in UTC by extracting the values from the original Date with the Original timezone. Then output that as a Bubble Date object and save it in your database.
If you don’t know the original timezone then you can only really ‘guess’ the initial intended Date - but rounding to the nearest UTC midnight (as you suggest) might be good enough for most purposes - it will be incorrect if any of the timezones involved are more than 12 hours difference from UTC (which some are, but you may not be working with those), and Daylight savings changes will probably also cause some errors - but it’s all you can do if you don’t know the original timezones used.
