13

You realize that, of course, the start of today in any timezone is (nearly) always 23:00 hours yesterday in the timezone immediately to the West, do you not?

(I say “nearly” only because of DST-type adjustments.)

You may have fallen asleep (who can blame you) during the part where I explained that dates represent a specific moment in time and that there is no such thing (web-wise) of a date without a time – or of a time without a date. DATES ARE TIMES: Specific moments in time, accurate to 1ms.

It sounds like you might have also missed the explanation of the differences between date construction and date formatting.

You might watch my overly-long video again with that info in mind, and then read this: https://moment.github.io/luxon/docs/manual/zones (at least, the first part of it, which is very much like how I explain these issues, but you might find more grokable than my presentation of it).

But on to what it is that you seem to be trying to do:

What you’re attempting to do (probably unnecessarily, mind you) is to implement a style of date recording commonly called “floating” dates. “Floating dates” are a concept where you attempt to throw out any differences between timezones and just say that (for example) 4 PM on 1/26/2021 just means 4PM wherever the user happens to be (or, more precisely actually, “in the user’s head”).

A common example of this approach:

We see this sort of system used in vacation rental systems (e.g., VRBO, Airbnb, etc.) where these systems publish ical feeds that publish dates essentially without timezone information. A user (who might live anywhere on the globe) books a property from some-check-in-date to some-check-out-date. The check-in / check-out dates are assumed to be in the property’s location and both the guest and the owner (both of whom who may not even in the same timezone as the property, of course) are presented these dates as exactly the same.

Like:

  • Guest, you will check in at Casa Fundido on 1/26/21 and check out on 2/1/21.

  • Owner, Guest will check in at Casa Fundido on 1/26/21 and check out on 2/1/21.

… even though the starting moment of 1/26/21 and 2/1/21 may in fact be different calendar dates for either the Owner or the Guest. (That is, the guest may in fact be checking in “yesterday” from the owner’s perspective, depending upon the relative position of the owner and the property, as just one example.)

They just handwave it away. A calendar date is the same for all users.

How does that work? How would you build such a system?

Especially if you understand how dates (by which I mean date/times) work on the web (by which I mean in JavaScript and, hence, in Bubble), where we know that dates are selected/constructed in the user’s timezone (by naïve datepickers), how do we ever make such a system work?

Well, to make that work, you first decide that all of your dates (proper date/times) represent dates in some fixed timezone. And that this timezone must not have DST adjustments, etc.

There is a timezone for just this purpose, and it’s called UTC (“Universal Coordinated Time” or “Coordinated Universal Time” - the abbreviation doesn’t match because of the French, who call this “Temps Universel Coordonné” and insisted on a compromise with the people who speak normal English. The nerve!)

Anyway, UTC is the time used on servers (and, not surprisingly, Bubble’s backend runs in UTC timezone – specifically the timezone known as “Etc/UTC”, but that’s the same thing as UTC or Zulu time – which is a more military name for UTC.)

So, to implement a “floating dates” approach, what we would do is construct all of our calendar dates as dates (proper date/times) that represent the starting moment of the calendar date in the UTC timezone.

And, when we wish to represent that date to the user, we format the date in UTC (as something like DD/MM/YYYY if you’re American or MM/DD/YYYY if you’re European). We can do this part (formatting the date in UTC) natively in Bubble.

Now comes the problem: How do we construct dates or pick dates in UTC?

Well, in vanilla Bubble, we cannot.

In my video, I explain how Calendar Grid Pro does this and there are other timezone-aware date pickers as well (like @gaurav has one that’s more like the Bubble default datepicker which will let you pick dates in a specific zone, like UTC).

We might also use whatever damn datepicker we want and then convert the picked date into what I call a “parallel date” in some other zone. This would require us to use a library to do so without tearing our remaining hair(s) out. I’ve shown how to do this in other posts using the moment library, but nobody knows what I’m going on about. :woman_shrugging:

Perhaps I’ll build that. What would you pay for that?