Happy August 31st! This is a special day. It’s a day that will break some of your date manipulations in Bubble.
Consider the following: Let’s say you have a calendar or something you’ve built. You need to navigate from month to month and display the name of the month the user is looking at. Easy, right? If you have an index representing a month offset, you just increment the month offset +1 for next and -1 for previous and the month the user is looking at is simply:
Current Date/Time+months:offset:formatted as mm (or mmmm or whatever you want that spits out months)
Not so fast. On August 31st, Current Date/Time+months:1:formatted as a month IS NOT SEPTEMBER. It is OCTOBER, due to the length of August and shortness of September.
[Clarification: You may not ever observe this happening, depending upon timezones of dates being compared and how you handle that in at the display level, but indeed for a certain portion the day, this problem can and will present itself. I wrote this post after observing exactly this phenomenon.]
That’s amusing, but no big deal. I guess I shouldn’t be lazy and use +months but just do the math indexwise. OK, so I’ll just get the NUMBER representing the month. That’ll fix it!
(Because an integer representing August will be 8 and adding 1 to it will yield 9 (representing September) instead of 10 as in the case of doing it with +months.)
Not so fast (again)… Bubble has no facility for extracting the month index as a number rather than a string. And no operator (like parseint/parsefloat) for typing a string to a number.
BTW, “day” of course can be used to extract an index for a day-of-the-week, which is very handy. However, a built in function for going from “Monday” back to its index would be handy. I’ve had to construct this myself by having a database object called day-of-week-long which is an array of days of the week and their indexes.
If one is patient, one can “do a search for” the day-of-week-long where name is “Monday” and return its index. If one is impatient, one can copy the list of day-of-week-longs to a custom state and do a :filter operation on the client side to return the index value much faster.
A similar scheme could be used to map Month names back into numerical indices, but what a giant PITA, right?
Bubble really really really wants us to do date math datewise, but a few missing features make this very very very difficult.
Seems like a bug because this was already addressed here:
“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”.”
Yep, I’m on that version of course. Point is this happens because JavaScript and date handling in the browser.
You can in fact divorce backend date stuff from presentation layer but in Bubble it’s overly difficult due to issues like this. (Long story short, in my system, there’s backend — api/api workflow—stuff going on that’s Timezone-aware. Those operations are more frequent than user interactions with the data, so even though it’s a bit of a pain, showing/selecting dates in the UI accounts for browser timezone differences… mostleee.)
