I’ve been working on a workflow that would only run when two date values differ.
Here’s the condition:
I happen to be using Air Date/Time Picker, but that shouldn’t be a factor in a simple Boolean expression like this. In a test, I displayed the two date values and the result of the conditional expression.
Clearly the dates differ but the Boolean comes out as though they are the same.
What do I need to understand about the is not operator?
Other related questions:
Why are the = and not = operators not available when two values being compared are text types (after modifiers are applied)?
Why are the is and is not operators not available for dates?
There’s an infinitesimal chance that two dates will be the same, unless you constructed them yourself. Dates are unique points in time. (Date objects are date/time objects with a precision of a millisecond – see many many posts I’ve written about the subject of date/time objects.)
What you’re seeking to do is check whether or not two dates share the same DAY part.
That is easiest to check by converting them to an unambiguous text form that eliminates the time component but keeps the month, date and year components.
In your example, you’ve selected ISO format perhaps? (Your texts that represent dates – shown in the first screenshot, still have times attached. Your second screenshot I don’t trust as illustrating the identical comparison as we don’t see your edit mode version of that text.)
But that doesn’t matter.
What you want to do is compare the dates text-wise, ensuring that both are formatted as something like mm/dd/yyyy (note that there is no TIME component).
So a date/time that happened sometime yesterday will be 10/09/2018 and a date/time that happened on “today’s” calendar day will be 10/10/2018. These will evaluate to “true” if we evaluate the “is not” condition on them.
This is a reliable and reasonable performant way to determine if two date/times did or did not happen on the same “day” as we would say, colloquially.
By extension, we could check if two date/time objects share the same year by formatting them as text in format “yyyy” and comparing them, etc.
Edit: I’m assuming that you want to check the day parts, but re-reading your message, I’m not so sure WHAT it is that you intend. I have no idea what the “ValueSet” custom state of your picker is (that is, what it represents) and why you care if it’s different from the time picked in the picker. I was just guessing.
But again, even if you DO want to compare two date/times down to the millisecond, the question is still WHY? They’ll only be the same if you constructed them. And if you constructed them, you already know they are the same.
Also, didn’t Bubble recently add equality operator for date/times? I think you CAN check that now. But mostly, the way it was before was fine, due to what I describe above.
Thanks, @keith, for stepping up with your thoughts on this.
You might say that I’ve constructed one date by copying into it the value of the other date. Therefore, there should be a 100% chance that they are the same until the user changes the date in the Air Date/Time Picker.
What I’m actually seeking to do is determine if the user changed the date and or time before closing/hiding the picker. Time is all that will change in most instances. It’s rare for most people to start a task before midnight and end it the following day unless, of course, she is a computer programmer.
Actually, the full date as “Simplified extended ISO” format is about as unambiguous as I can imagine, and I need the time component because this whole exercise is a response to the fact the Air Date/Time Picker fails to trigger the “value is changed” event if only the time component is changed. That problem is what I’m attempting to work around.
At this point, I have a workaround that suffices in a “calendar is hidden” workflow where I can successfully work with the user-selected date and time even if unchanged from the previous value of the picker.
It remains very curious to me that is and is not are usually stand-ins for = and not = but the is/is not operators aren’t generally available when the operands are of type date.
I appreciate your thoughtful observations on this.
