In general it is problematic to try to impose restrictions like this, not just for names but for many types of data. The robustness principle is really the best way to go, in my experience: "Be conservative in what you send, be liberal in what you accept."

I once was filing my taxes through a commonly used US tax application and my employer for part of that year had been sold to a company based in Canada (where postal codes contain letters and numbers.) When I went to enter the postal code, I was informed that the postal code I was trying to enter was invalid because it must only contain numbers. Then is pestered me repeatedly that the postal code was missing. It was really obnoxious and unnecessary.

In your situation, if you have issues with certain types data, you should probably have a exception process after the input has been captured and inform a human to evaluate the situation. Even then, if you happen to get unlucky enough to get someone actually named '2016/09/08' then you are SOL.

In general it is problematic to try to impose restrictions like this, not just for names but for many types of data. The robustness principle is really the best way to go, in my experience: "Be conservative in what you send, be liberal in what you accept."

I once was filing my taxes through a commonly used US tax application and my employer for part of that year had been sold to a company based in Canada (where postal codes contain letters and numbers.) When I went to enter the postal code, I was informed that the postal code I was trying to enter was invalid because it must only contain numbers. Then it pestered me repeatedly that the postal code was missing. It was really obnoxious and unnecessary.

In your situation, if you have issues with certain types data, you should probably have a exception process after the input has been captured and inform a human to evaluate the situation. Even then, if you happen to get unlucky enough to get someone actually named '2016/09/08' then you are SOL.