Yes, most likely, @subtlemonsters. I’ll read this thread more carefully in a short bit and advise.
A couple of fast facts that may help you:
-
Note that date objects (as I’ve said many many times here) represent unique moments in time. These are accurate down to the millisecond, so unless you’ve constructed them yourself (setting the time parts – HH:mm:ss:ms – to zero or some other reference time, a strict comparison will almost never match).
-
Two things are “on the same date” if they both happen on the same day with respect to ONE date object’s time zones. Consider:
2a. As I write this, my local time is 6/25/2019 7:24 PM in timezone ID America/Los Angeles (I am in San Francisco, but this is what the timezone is called – bastards!!!)… Let’s call this date “2a”.
2b. In UTC, it is 6/26/2019 at 2:24 AM. Let’s call this date “2b”.
On the face of it… “NOW” is not the same calendar day in these two timezones! Whoa, mind blown, right? These dates (date/times) are exactly the same but they “happen on different days” . WTF, right? Well, the WTF part is we would be doing it wrong to compare them that way…
2c. Clearly, to determine if two dates share the same day part, we must transform both dates into ONE consistent timezone. In a Bubble page (in fact in any web page), we would do this as comparing the day parts of date “2a” and date “2b” this way:
We would probably give primacy to the User and compare. If we take my current time as an example, the following boolean (“yes/no”) expression is true (“yes”) if both moments in time happen on the same day from my perspective:
2a:formatted as MM/DD/YYYY [in timezone User's timezone] is 2b:formatted as MM/DD/YYYY [in timezone User's timezone]
^^^ this is shorthand, but you should know what I’m getting at.
What this will yield is a comparison of “6/25/2019” and “6/25/2019” and these are the same, right? So the expression is true.
If our workflow is a server-side workflow (API Workflow), we would likely compare UTC time. You can also see that if we did:
2a:formatted as MM/DD/YYYY [in UTC timezone] is 2b:formatted as MM/DD/YYYY [in UTC timezone]
… will also be true, but in this case the strings compared will be “6/26/2019” and “6/26/2019”.
- In JavaScript (and hence in Bubble) and in nodejs (which is just JavaScript that runs on a server and so hence in Bubble) dates can only be created in the browser timezone. This means that a date created by most datepickers that a user would interact with will only be created in that user’s timezone. Since there’s no browser server-side the dates get created in UTC… and not from a datepicker but from some other process, right?
(This is why there is a timezone option in Calendar Grid Pro. It allows the selection of dates in other zones if you desire.)
The Bubble server timezone is effectively “UTC” though note that what it actually reports is “UTC/Etc” – these are the same thing, though they have different timezone ID strings. (That is, representing a date as text based on UTC and UTC/Etc, we will find no differences.)
As you can see from the above, you don’t necessarily need JavaScript to do a “on the same day” comparison of dates in Bubble.
But you do need to do it the way we would do it in JavaScript, which is to (thoughtfully) convert significant parts of the dates in question to strings and compare them that way.
Libraries like moment and moment-timezone are really only necessary when you need to construct date objects. (Which is a thing one might need to do in advanced applications that handle dates.)
- Believe it or not, a lot of advanced applications handle dates in a pretty damn hand-wavey way. And this is where UTC in part comes from and comes into play. Let us consider a vacation rental booking app that:
-
Allows a user to book a vacation rental property at some time in the future. and such property may be anywhere in the world.
-
I am the user and I want to book a property in London (which is sort of in UTC timezone). But I live in San Francisco.
-
I book the property for July 4th through July 8th 2019.
-
I use a date picker to select check in of July 4 and check out of July 8.
-
Most date pickers (and in fact the one I’m using on stupid vacation rental site X) can only understand that I am indicating July 4 and July 8 in my time zone.
-
So what stupid vacation rental app does is just assumes that I mean July 4 there – in London – and, at the end of the day, just stores that as July 4 hour zero (start of day) in UTC… NOT because London is in the same timezone as UTC, but because that’s a convenient way to store dates. But dates are never separate from their time parts because dates are distinct moment in time.
But that’s typically how that works. Using Bubble and a clever plugin like Calendar Grid Pro, you can actually store the REAL TIME (the real date) that the user is selecting. (Because I actually construct the check in/check out dates in the target property’s timezone.) But I don’t think there’s many real life apps that do it this way.
When we examine iCal feeds from booking sites, we see that what they do is just store “July 4 at zero hours in UTC” and then conform all selections to UTC.
It’s like a way of saying, “Look, I can’t get what this date looks like to YOU, user. But we both understand that you will arrive IN LONDON on July 4… even if the REAL July 4 hour zero in London is some other time on July 3 or July 5 FOR YOU.”
Does that make sense?