We’re making some changes to the way date manipulation works.
To roll out these changes in a way that doesn’t break apps that depend on the existing behavior, we are using the new “Versions” tab of the editor. See here for a description of how this works: Important new tab in editor
The potentially backwards-incompatible changes are:
All operations that perform calendar-aware math, such as adding a month to a date, now do it in the context of the timezone reported by the user’s web browser. This includes scheduled and recurring workflows: we remember the timezone of the workflow that originally scheduled the event. Previously, our behavior here was inconsistent: in the user’s web browser, we used their timezone, but when running workflows, we used the UTC timezone, with the exception of “change hours” and “extract from date”, which did take the user’s timezone’s offset into account, but didn’t take into account changes in offset such as Daylight Savings Time.
The behavior when adding a month or changing the month such that the new month is shorter than the old one is different. Previously, adding one month to Jan 31, 2018 would give Mar 3, 2018, because Feb is three days shorter than Jan. Now, adding one month to Jan 31 gives Feb 28: instead of rolling the extra days over, we clamp them down to the last day of the month. We think this behavior better captures what people intuitively expect when they add “one month”.
The behavior when adding fractional days, months and years are different. We now round days and months to the nearest whole number prior to adding them, so adding 2.9 days is the same as adding 3 days. Fractional years are rounded to months, so adding 0.51 years is the same as adding 6 months. Previously, adding fractional days, months, or years would give you some indeterminate amount of time roughly equivalent to the fraction. This led to strange inconsistencies when dealing with days and months of different lengths (for instance, 23 or 25 hour days caused by Daylight Savings Time), which is why we are changing the behavior. If you do want to work with fractions, you can convert to hours. Hours perform absolute, not calendar aware math: adding one hour in Bubble is always equivalent to adding 3,600,000 milliseconds, and adding a fraction of an hour gets rounded to the nearest millisecond, so adding 0.51 hours is equivalent to adding 1,836,000 milliseconds.
Keep in mind that none of these changes will apply to your app until you upgrade the app to the latest Bubble version in the new Versions tab of the editor.
As part of this release, we’ve significantly expanded the section in the reference on dates: if your app depends on doing date calculations, we recommend reading it: https://bubble.io/reference#Data.Messages.date. The reference always reflects the latest Bubble version, regardless of what version your apps are currently on.