Problem with date range

Hello to all guys. I’m trying to put a condition where I set that IF THE CURRENT DATE is NOT included in a field within my database (with a range value) then that element must not be visible. However, I am having difficulty setting the condition. Can you help me?

Basically I should say, if the current date is not in the range (circled in red) then don’t show it.

You’re looking for the Date Range operator :contains point.

If we have some date Date and some Date Range, the following expression evaluates to true (yes) if Date lies within Date Range (inclusive of the start and end points of the range):

Date Range :contains point Date

:point_up: This is the general case of how we can know if some specific point-in-time is within a range of times.

Note that it looks like what you are doing is trying to figure out if some date happens on some specific day (August 6 in your example screenshot). In this special case, there’s another solution.

If we want to know if two dates (let’s call them DateX and DateY) happen on the same day, there’s another way to do that (which does not require us to construct a date range). We can simply compare the dates string-wise:

DateX:formatted as MM/DD/YYYY is DateY:formatted as MM/DD/YYYY

2 Likes

For a little bit more on date range operations, see my post reply here: How to use the range funtions - e.g of how to use it

1 Like

Hi @keith I have a similar question,

How can we set Does not contain point

I’m trying to say “When the dates are outside the range it’s not clickable”

To negate a yes/no value in Bubble, we simply ask if it is no, thereby inverting the value from yes to no and vice-versa. Like so:

some-boolean is "no"

:point_up: If some-boolean is yes, this expression evaluates to no. If some-boolean is no, this expression evaluates to yes. Viola… boolean negation! (It’s true that this syntax is hopelessly and utterly stupid and non-intuitive.)

But wait… it gets stupider!

Unfortunately, you can only build this expression if some-boolean is a literal, actual boolean state (meaning that it must be a boolean Custom State or a boolean output state from some other Bubble element, server-side action, or plugin).

But (because of the oh so “special” way the Expression Composer works), if some-boolean is not the literal name of a state but some boolean expression (e.g., some_range contains point some_date), we do not have access to the :is "no" or :is "yes" boolean operations.

That is, we can never in an expression field build the expression:

some_range contains point some_date is "no"

:point_up: THIS is the expression you’d want to build (it will be FALSE/no if some_date is within the range, and TRUE/yes if the date is not in the range). But, you can’t build that.

SO, you have several alternatives (in no particular order):

  1. Precompute the expression and store it in a Custom State. Then you’ll be able to build that_custom_state is "no". (This requires executing a workflow to Element > Set State which is kind of overkill, if you ask me. See below for 3 no-workflow-required solutions.)

  2. Just say, “eff it” and treat the “no” state as the default state and the “yes” state as the state you treat differently. (All this requires is a user headspace change.)

  3. Use a stupid expression hack: Even though you can’t build an expression like some_boolean_expression is "no", you CAN build (and this is incredibly frustrating): some_boolean_expression :formatted as text [you'll get a dialog here] :is "no" … to which you’re now like, “You’ve got to be fucking kidding me. I can’t negate a boolean expression, but I can convert the boolean to text and then do a stringwise comparison to turn the text BACK into a boolean value!? WTELF!?” But it’s true.


:point_up: one of the more ridiculous Bubble expressions you’ve ever been forced to build… but it’s pretty expedient and, in the grand scheme of things, not really any different performance-wise from having a truly boolean expression. But this should offend our sensibilities to no end. (In fact, how is this NOT a bug?)

  1. Use some handy plugin like List Shifter – which has a scalar input (that can be of any type, including a boolean) that’s echoed to the plugin’s scalar output whenever the input value changes. You can then read List Shifter’s Scalar output and put :is "no" after it. Like this:


:point_up: This List Shifter just takes a boolean expression (which we put in the “Use Scalar” field), computes it, and passes the result to List Shifter's Scalar output. Any time the value of the expression changes, the value of List Shifter's Scalar output changes (damn near instantaneously). And, since that output is of boolean type, we can write the expression List Shifter's Scalar is no.

This might seem like a “hack” (like #3 is a “hack”), but this is in fact a use case for which List Shifter is designed. There are many times that you want to evaluate some expression and be able to actively react to (or passively consume) changes to that expression and List Shifter gives you this ability.

(In olden days, people would use Input elements that are styled in such a way as to be invisible to do this, but List Shifter is a better way to accomplish the same thing.)

3 Likes

This topic was automatically closed after 70 days. New replies are no longer allowed.