Not a misunderstanding, I'm sure they understand birth dates. But that the date picker selects the current time by default, and doesn't make that visible to the user.
There should be no time component to a properly-stored birthdate. One doesn't observe a "January 1 in Australia" birthday on December 31 in New York. Systems that presume a birthday to be other than a year+month+dayofmonth get themselves into the sort of trouble described in this thread. Birthdays well in the past, however, might need more information on the observed calendar/chronology in use in the subject's locale.
OTOH, if you need "instant of birth" then definitely get a time and timezone. Plus, converting to UTC and discarding the timezone observed at the place and political circumstance of birth would likely be a mistake.
I feel you're being pedantic. The misunderstanding is not around the concept of a birthday, yes--it's due to the use of a time-having datetime datatype for this purpose, in UI and/or application server or database layers, the latter of which ought to reject datetimes as nonconforming inputs.
Birthdates are complicated. It's quite possible for you to tell someone your birthday and be "wrong" because of the timezone you are in. Or for you to be more or less "years" old than your birth date indicates because of timezone differences between where you were born and where you are now.
Rarely matters. Simple mistake in code to forget that a birthdate should be treated as having no timezone.
Depending on time of birth it could have been you that was off by one
