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.
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”.
I am trying to understand why i can’t seem to get the correct date even after this update. I am trying to take a date from one entry and the time from another entry to make the correct .ics (Calendar) file. For some reason when I create this .ics file it always shows up 1 hour earlier than it should. I save it as 7:30pm and the calendar file shows it starting at 6:30pm. The date is correct though. Although i have some people that use the program in another country and they say it shows the day before for some reason. Any help? I am stumped. I thought maybe this update was going to fix it. I don’t think it did. Unless I’m just doing something wrong. Help please!
It might help to know that
“week1DateICS” = 04/07/2018 12:00 am
and
“MeetingStartTime” = 09/01/1940 07:30 pm
So i thought my calendar file would show 04/07/2018 7:30 pm but it shows 04/07/2018 6:30 pm
Could you submit a bug report for this? Also let us know if the date is saved incorrectly in the database as well after sometime or just the calendar file.
How do I go about making sure that a scheduled api workflow is triggered to happen at midnight for a particular timezone? I need to ensure it is triggered at this time only.
Yes! It takes into account leap years, daylight savings time, and any other time zone related weirdness as tracked by https://www.iana.org/time-zones
Not right now, but I see how that would be useful – I’ve added it to our list of features to build. The way it would work is that you’d need to save the user’s timezone somewhere (since it can change – a user might log in from multiple timezones), and then we’d have a “set timezone for workflow” for action that would change it for the remainder of the workflow
Can you please confirm that I’m reading your first bullet correctly.
– Is the change limited to math functions on dates and scheduling an API workflow. These both will now use the User’s browser timezone?
– Is the Current Date / Time field in the API workflows now using the User’s browser timezone as whereas Current Date / Time in the API was previously set to UTC
Thanks for rolling this out in parallel with the new staging suite! We’re going to need it.
Sorry, to be clear, this does not change how the schedule an API workflow action works. The action still takes a Bubble date, and will run it at that date. Bubble dates represent precise moments in time. 4/12 11:10 am in New York is displayed as 4/13 1:11 am in Sydney, but it’s the same moment in time no matter how it is displayed. The only thing that this update changes is how functions that work with dates work. So if you extract the hour component from a date, you’ll get something different depending on what time zone we are in. But the “Current Date / Time” field always equals the same moment in time no matter where in the world you are… it just gets displayed differently. (To see this, you can extract the UNIX timestamp from the Current Date / Time – that’s how we store dates behind the scenes, and you’ll see that the UNIX timestamp is the same number no matter which timezone it gets displayed in)
Also, it’s not new behavior that we remember what time zone an API workflow was scheduled in and use it. Even on the old version, “extract from date” used the user’s browser’s timezone even if running in a scheduled workflow. The difference is we weren’t consistent; most messages, like changing the day or month, didn’t check the timezone, it just used whatever the current computer’s timezone was (which is UTC for our servers). So the old behavior was bad and buggy; the new behavior is much more consistent.
I have an app that uses date manipulation, but I don’t remember all places. It would be nice to have a function “list all places in the app using date manipulations” something like the Issue list. This to see the to what extent I need to rework the app and to not miss anything.
I’ve read the release and the documentation but still would like to verify something as this is a crucial part of my app.
My apps relief heavily on converting timezone-dependent dates into unix to store in the DTB and serve this as static dates. All my important dates are local dates so no matter where a person is, the date they are looking at is understood as the local time/date.
This works now and I think this upgrade does not affect this, but still would like to double verify before I hit the switch. @josh
