Right. You’d just store the date object, @mebeingken. You can set the time parts to 0 if you want before storage or as part of retrieval. If you really want to do this absolutely “correctly”, you would want to normalize birthdates to some arbitrary timezone (like UTC is often used for this purpose but in fact you could pick ANY zone).
Moment has a UTC mode for things like this.
And then, when a searching user is specifying start and end dates for which to find (for example) all users with birthdays between those two dates, you’d convert the start and end points of the search to the chosen arbitrary zone (in the way I describe in the original post).
Essentially the above is what I do in my vacation rental calendars. And it’s more-or-less what things of that nature do. For example, an iCal URL from HomeAway or VRBO lists start and end dates for a reservation where the start and end dates are assumed to be the first moment of the day in question. And there’s no timezone metadata attached.
Here’s an example of a typical iCal VEVENT like this:
SUMMARY:Reserved - mary & millard anderson
See how there’s no timezone info except in the datestamp field? (that’s when the file was generated)
So what do you do? Well, it depends on how and when/where you turn those text values into real date objects. If you’re doing it in the browser, the start and end dates are going to appear as though they are in the browser’s timezone.
If those texts representing dates are brought into Bubble via the api connector (and you tell bubble “hey, these are dates”), they’ll get turned into dates at start time 0 on that day in UTC.
What I actually do is I have an API that does the conversion before passing back the dates. And it passes them as texts (of course), but they are fully specified simplified extended ISO date texts and so they have all the timezone info in them. And my API actually takes an input for timezone – the dates that get passed back are transmuted to that target timezone.
This is a little bit fancier (but not much!) than just assuming UTC. (You still have the challenge of presenting the information in the user’s browser in such a way that it appears that the UTC dates actually start and end at the correct time when shown in a calendar.)
Long long long story short, if you have a datewise comparison and all of the dates under consideration are from the same timezone, you don’t have any of the weird issues that you’re anticipating.
But to @seanhoots more recent point: Birth dates are like the dates I showed you in that iCal feed. A user is born somewhere and likely does not currently reside where they were born, but of course just enters their birthday as the date upon which they were born, without consideration of timezone issues.
Basically, when we ask the question: “Out of a batch of people, which ones were born between date X and date Y?,” what we are doing is saying/asking, “Assuming that everyone’s birthday, date X and date Y are in the same timezone, which birthdays are in that range defined by X and Y?”
“Ignoring” the timezone aspect is assuming some sort of unified timezone (which we might call a “null” timezone) shared by all of the dates that we are considering. We are also at the same time ignoring time components and setting them to 0 in our heads.
You can pick whatever timezone you want to represent this shared or null timezone.