Business/requirements/users will often tell you that no two users will have the same birthday/SSN/whatever, but so often that eventually proves incorrect. Just using an auto increment ID as the primary key can prevent a lot of pain down the road.
So, when someone comes to you and identifies herself by providing her SSN, name, date of birth, how do you know whether she corresponds to the record with id M or to the record with id N? Or, more likely, to one of the N records, with N>2, with that SSN, name, date of birth?
I think this was the parent's point. Since, as you point out, we we almost never use the data itself (e.g. date of birth) as the primary key, the parent is asking why is this a feature at all? Why not just mandate a uuid, number, etc. as the primary key?
Well it's easy enough to think of a situation where you would use a date as a primary key, for example time series data.
What about them? Do they really exist, practically speaking?
At a quick glance on my databases, I see nothing of the sort.
Is there anything comparable to the birthday paradox, which includes years, by the way?
I would guess that you would need a big group of random people such that there is a high chance of having two people born the very same day.
The birthday paradox threshold if years are included would be 23 people per year, rather than 23 people in your database. What that translates to in your database depends a lot the age demography of your userbase. If people live to be 100, and if I don't worry about the fact that some years will have more people than others even if they are randomly distributed (something that should go in to the model), that's about 2,300 people before you start expecting to see duplicate birthdays.
I don't think the birthday problem accounts for year, but yet it's clear some people share the same birthdate, twins for example.
I share the same name and birthdate as another individual. It has actually caused me to be held up at the border before.
What gave proof that you were not this individual in the end?
But not birth time and birth location.
Are we seriously discussing whether in practice, two people can be born on the same day?
This was an absurd joke. A person looking at their database using birth dates as a primary key can obviously only see people with different birth dates.