I’m about to file a bug report, but figured I’d ask in here first. We have a booking system for a client. For legal reasons, a booking can only be made no less than 1 calendar month into the future. We are using this for determining availabilities and adding the 1 calendar month:
We have also tried a variation adding ‘+days: 0’ at the end. But I suspect there is something going on with the rounding.
Today (being 18th December, 2024 in Sydney), we are unable to see any availability on the 18th of January. From how we have set the data source above, we should be able to, right? The only thing I can think is that the rounding is not actually rounding DOWN to midnight, but rather perhaps the TIME OF DAY this is set as the issue does seem intermittent.
The availability on the calendar does NOT allow a booking on the 18th of Jan, which according to the availability and (WHAT WE BELIEVE TO BE) the correct way to calc +1 calendar month from today, it should allow this.
I am by no means an expert, but if you want your users to see availability at any time on the 18th after 12am - say 9am, your setup would exclude that possibility.
I think what you want is for users to see availability INCLUDING the entire day in question, the 18th. So the rounding down is limiting you. You could add (+ 23 hours + 59 minutes + 59 seconds) Or add (+1 month + 1 day - 1 second) to your original expression to capture all day on the 18th.
There must be a better way to do this, but this is what I have done.
Which is as expected (Today is Dec 17 for me). I am not sure of your setup from looking at your datasource, but you might not be capturing things later in the day if you want to. If I was using this to filter a RG for things happening on Jan 17th after 12:00am (like bookings), they would not appear.
If you use Current Date/Time Rounded Down to Date + 1 Month, the result is identical.
My tip would be to put a text block on your page and show the various solutions in Unix timestamps so you can figure out what the different options do.
Time is always a tricky thing
Don’t forget about time zones and the difference between how bubble stores time and what you see.
Also, not sure how important it is, current date time is not updating all the time. So suppose someone is on the site 5 minutes before midnight and books 5 minutes past midnight, current date time can allow a booking one day earlier.
When performing calendar-aware math, fractional amounts are rounded to the nearest integer, so adding 0.9 days is the same as adding one day. The exception is adding years, which are rounded to the nearest number of months. When performing absolute math, fractions are rounded to the nearest millisecond, so adding 1.2005 seconds will add 1,201 milliseconds.
The main exceptions to this rule are the “+(seconds)” and “+(hours)” operators, which perform absolute math: calling them with an argument of 1 always adds exactly one second and 3,600 seconds respectively to the given moment in time. Note that the “change hours to” and “change seconds to” do perform calendar-aware calculations. Absolute math is not impacted by timezones: if two users in different time zones call “+(seconds)” with the same argument on the same date, they will get the exact same moment in time as the result (though that moment in time will be displayed to them in their local timezone if the result is displayed on the screen).
I spent months with Support and my own troubleshooting on my app working on items exactly like this along with always showing info in a client’s preferred timezone, etc…
Candidly it gets quite complex and in that time I submitted dozens of tickets that I thought were slam dunk bugs. They weren’t, but this type of date math (again made more complex with timezones) definitely doesn’t work as one would expect in a purely linear view.
What I ended up doing in my use cases was doing a lot of rounding down, then adding months/days/etc., then rounding down again where necessary. This always made sure I got exactly what I wanted.
As mentioned, something I did probably 10,000 iterations of was creating a blank page and making a bunch of text elements with all various date math calculations, changing the time and timezone on my computer to see how they shifted, etc. and ultimately just figuring it out.
In my experience this has been true as well. It certain cases I guess one would be preferred over the other, but I have not seen any difference and use both interchangeably (unintentionally) in my app.
Thanks for the tips. Our problem was not strictly rounding related, but we did need to set a call to be essentially minus 1 second before midnight to get the following day into what we were seeking.
