[01]: one- or two-digit day, typed manually
[Jan]: three-letter month, picked from a dropdown
[1970]: four-digit year, typed manually
I think this is a good (the best?) presentation.
By using a manual day entry instead of providing a dropdown, as the programmer you can avoid requiring client-side logic to restrict the number of days displayed in the dropdown based on the chosen month and year (e.g. 31 for Jan., 28/29 for Feb., etc.).
Having the month represented in letters, not numbers, minimizes the chances of user confusion between `dd-mm` and `mm-dd` presentations.
The year presentation matches the one in the OP article.
> I think this is a good (the best?) presentation.
I don't think so. It has problems with i18n. For example, the abbreviation for December is "Dic" in spanish and "Dez" in German, not "Dec" as in english.
The twelve month names for the month dropdown could be localized, unless I'm missing something. The entries don't necessarily have to each be three characters; they can be longer if the localization requires it.
DOB should always be a typed input, all numeric. People know exactly what to enter (the number of their month), have done it before many times (DMV etc.), and will knock it out faster than some ridiculous drop down over complicating the process.
For other dates though maybe, since most wouldn't have all month numbers memorized, but I’d still say typed, only with a variation on month name (you should be able to parse both abbreviated and full, so long as you know their locale) is better all the time.
By using a manual day entry instead of providing a dropdown, as the programmer you can avoid requiring client-side logic to restrict the number of days displayed in the dropdown based on the chosen month and year (e.g. 31 for Jan., 28/29 for Feb., etc.).
Having the month represented in letters, not numbers, minimizes the chances of user confusion between `dd-mm` and `mm-dd` presentations.
The year presentation matches the one in the OP article.