Is it a bug?
But the old conditions with “is not” are still staying and working. And It only happens with date. Who else faced this issue?
Is it really happening only to me? Weird…
Format the date as a text (I use simplified ISO) then ‘is’ the other date formatted the same way
You’d think I would know this, but I can’t recall if the date data type in Bubble ever had “is” and “is not” operators.
If so, this seems to have been replaced by the :equals rounded down to...
operator.
However, :equals rounded down to...
doesn’t have a Component option for milliseconds, which is abjectly stupid. (Obviously, when we look at milliseconds, we are not “rounding down” as that’s the granularity of JavaScript date objects, but this should be a selection.)
I note that if you write the expression:
some_date:equals rounded down to... is some_date
And leave the Component field empty, the Expression Builder considers the expression complete, but the issue checker still throws an error suggesting that you must complete the Component field.
That expression will return true (“yes”) as if the date had been compared at the millisecond level. If we change the expression such that the first and second dates ARE NOT the same, the expression returns false (“no”), which suggests to me that the dates MIGHT be being compared at the milliseconds level, but it’s hard to be sure.
At any rate, the bug would seem to be that :equals should let you compare down to the ms, and that should be reported as such by someone who cares.
For a ms-level comparison using numeric values you can :extract UNIX (which yields the date as a number, the same as if we did some_date.getTime() in JavaScript) and you can is compare that with another date :extract UNIX. Like:
Of course, most Bubblers are not usually trying to compare if two dates are literally the exact same moment, but whether two dates (for example) happen on the same day.
Aside, if dates ever DID have “is” and “is not” operators, but now do not, this would be one of those rare instances where Bubble expressions have been made more consistent with JavaScript.
In JavaScript, dates are a type of object (and not some specific, fundamental data type). Objects are unique and so the only way that two Date objects can be equivalent is if you’re comparing two object references that refer to the same object.
So, somewhat confusingly, if you do this in your console (create two dates with the same time value):
a = new Date(42)
b = new Date(42)
And then ask, is a equal to b? You will get:
a == b
// yields false
because a and b are, in fact, not the same object.
But you can ask “is a less than or equal to b?” and find that this is true:
a <= b
// yields true
Because the relational operators (<, >, <=, >=) – unlike the equivalency operator – for Dates compare the time value held in the Date.
In JavaScript, to assess whether two Date objects represent the exact same moment in time, we must compare their UNIX time values (just like in Bubble at the moment):
a.getTime() == b.getTime()
// yields true
Not to mention the epic risks of formatting JavaScript date-time strings to a specific time-zone and the utter obscurity of working with time-zones in general.
This topic was automatically closed after 14 days. New replies are no longer allowed.