"Date of birth" validation: How far/much would you go?_问答_开发者

I'm quite anal about form validation. So while creating a validator for a "data of birth" (DOB) field in one of my current projects for a job application form (platform/language is neutral in this context), I wanted something to prevent 'punky' inputs.

I us开发者_StackOverflowed a date picker and restricted the max date to be XX years from the current day. XX make sense for this scenario as anyone younger shouldn't be even applying for the job.

The validation error message is: You seem too young for the job.

Then I began to get adventurous. How about?

If DOB is more than 120 years ago, message: "You cannot be that old!!!"

If DOB is in the future, message: "You must be kidding, you are not born yet!!!"

In the end, I deployed without the last 2, too cheeky for my no-nonsense client.

I would like to know how far/much would you guys go to validate DOB fields for good usability (or humor)?

Similarly for dates like, "Date of marriage", "Year of graduation" etc...

PS: As I was about to submit this post, there's a warning under the title textbox: "The question you're asking appears subjective and is likely to be closed." Fingers crossed.

To add: I'm quite surprised that some/most of the guys are not too concern about the validation. I repeat one of my comments here:

If the user entered the date wrongly (something very obvious) whether by intent or by mistake; that's one of the purposes of the validators to catch it. When data goes into the system, the site owner only know the input is wrong, he/she would not know the actual value without asking the user. If this field is highly important, it will not be a pretty scenario.

Think about the times you've filled out forms. How many times have you been frustrated because some "overly clever" programmer inserted some "validation" that just happened to be incorrect for your circumstance? I say, trust the user. Come to think of it, as time goes on I guess people are living longer and getting on the net at earlier ages, anyway. :P

don't forget you can also warn the user against unlikely values. In most cases, a typo is more likely than deliberately being awkward.

So for your application, maybe something like this:

Age < min. applicant age - error
Age > common retirement age - warning
Age > expected life span - error

Validation vs. Correctness
The point of input validation is to ensure all elements are within the range allowed for and expected by further processing - i.e. if your database guarantees all applicants in the DB are 18 years or older, validate that. If your database also accepts school kids applying for internships, don't.

Everything unusual is just a warning. Yes, a value of 120 years is crazy, you should warn the user and possibly flag this record as suspicous / for review. However, there's no point in rejecting it (unless you have a business rule that e.g. all applicants are younger than 70).

Fake trust
Imagine what happens if you tell one user that "you rule out unlikely DOBs at the input". She might tell her co-worker that DOB is "already validated". He ends up with an unfounded trust that the applicant is 90, and if it were a fake you would have rejected it.

All further processing - by human or by computer - must still assume the DOB may be incorrect - just because of a typo. You are trying to create a guarantee you can't actually make. Many users trust the computer they use every day more than a stranger, you are trying to enforce this trust - which is IMO s fallacy.

Transmutation
Many applications live much longer than the original implementer imagined, and quite some will be used for purposes beyond his wildest dreams. Building in artificial limits that neither simplify the actual processing nor the job of the operator don't actually help.

(That puts me probably into the no-nonsense category of your client - but thst's my way to be "anal about validation": knowing when to stop :))

I think validation is incredibly important, but not necessarily in your situation. Which isn't to say that your situation is trivial, I just have my own date-oriented nits to pick.

Specifically, my concerns are always in keeping things in logical order. If someone says they were born in 1802, that's fine (sorta), I just want their date of graduation to be greater than their date of birth. But you run into itchy little problems when it comes to time (as in hours and minutes), for instance, if a user chooses 8:30 as the start time and then chooses 9:15 as the end time, but then realizes that the end time was 8:45. They decide to change the 9 to an 8 with the intention of changing the minutes to :45. But my validation script is too busy saying "Hey Wait! 8:15 is before 8:30, nice try!" but I can't risk letting them leave it wrong, etc etc.

For your situation specifically, I would lean toward what is ethical right. Because as it's been pointed out, someone could be entering a family history (with DOBs in the 1600's) or future purchases (with dates after today), so there is no realistic limit on dates in general. But there are limits to your scenario, ie:

If Age is less than legal working age (16 in most parts of the US), don't even offer anything higher than that year as an option (if you are using drop down).

If Age is beyond reasonable working age (which can be a sensitive subject) offer the highest value based on retirement age and simply add a ">" in front of that year. If someone is 75 and applying for an admin-level job, they will be more pleased that you made things simple rather than offended that you didn't have their year of birth listed. If anything, they will be impressed (I think) that you went this route instead of nothing at all, implying they shouldn't waste their time.

In the end you have a simple drop down very easy to script (example in PHP):

$currentYear = date('Y');

    echo "<select name=\"YearOfBirth\">";

for($i = 16; $i <= 64; $i++) {
    $optionYear = $currentYear - $i;
    echo "<option value=\"$optionYear\">$optionYear</option>";
    }

    $greaterYear = $currentYear - 65;
    echo "<option value=\"&gt;$greaterYear\">&gt;$greaterYear</option>";

    echo "</select>";

When asking living people for their birthdate, only reject values that are definitely wrong. Any birthdate in the future is definitely wrong. And I would draw a line and say that any birthdate before (say) 1880 is definitely wrong. Anything else is a valid birthdate.

So any birthdate that fails the above tests is rejected with a message at field level, like "This date is in the future/too far in the past. Please enter your birthdate."

Any other birthdate is valid (maybe the user really is 11 years old, or 108). But the overall form may be rejected by business rules. For example, "You must be at least 18 years old to apply."

The idea is to separate individual field validation from form validation. Conflating them yields complicated rules. Separating means you can re-use the rules for the field (e.g. "DOB of a living person must be between 1/1/1880 and today") in other contexts.

If you're doing this for anything professional - like a job application - I might not use "!" in messages to users. Take a look at any well done website you'd like, you're not going to find it in common use.

Valid date: check
Date not in future: maybe (I deal with medical applications, so I suppose you could be treating unborn babies)
Date not older than 120 years: probably

I'm not a big fan of over-engineering these things, particular if a user mistake is relative harmless and can be spotted and fixed easily. That's how I approach it anyway.

Valid Date:

I'll go to the extend of checking whether this date exists or not. i.e. leap year 29th Feb and so on

Date in the future:

we usually check the age (this year - dob given) and must be at least a certain age to sign up.

Date older than 120 years or not:

I won't check. 200 years would be a safer limit? (in case a 121 year old man wants to use the computer *chuckles*)

I think you should consider your actual requirements when designing validations. Yes if the field is a date field (and perhaps more importantly if it stores a date but some less than stellar dba made it a varchar),make sure only a valid date is submitted. This is critical. Invalid dates cause all sorts of issues with querying the data. If it is a date that must of necessity have occurred in the past, limit the date range to the present date or earlier.

After that go with what your client wants. If they want to pay for you to eliminate people younger than work age, they will tell you. Disallowing a top age limit can get you into legal trouble for age discrimination. The client may not want you to do this either.

Humour is a pretty subjective thing and very project specific so it’s a bit difficult to answer along those lines. Having said that, if the application supports a formal process such as applying for a job I’d probably err on the side of caution and keep it pretty factual.

As for validation, I believe the effort so you go to here should be proportional to the impact of invalid data making its way through from the UI. Going back to the job application form, I imagine there will be a human review process at some time so the risk of invalid data is minimal whether the data was intentionally or inadvertently entered incorrectly.

If you’re worried about “punky” or bot driven inputs then use Captcha. Having said all that, I reckon you’re pretty safe with the validation rules you’ve used.

Well I'm not a programer (More of a BA) though I'm trying to gain some development skills as I think it may help me be a better BA. I've done a bit of VBA (Don't laugh).

Anyway in thinking about this here's my two cents

1) Dropping the humour. Whats funny to you now won't be to someone else. Furthermore, whats funny after two or three goes isn't funny after 25 or 30 - its just tiresome even if you are dealing with a jokey crowd! 2) I am coming round to the idea that unless you can definitively validate something as being plain wrong, E.g. you don't want to let someone enter a value < 0, then you should consider warning rather than prevention via dialogues or whatever the OS standard happens to be.

Hey what do I know, In a week I'll have changed my mind (I'm a Business Analyst) and will be demanding instant repsonses from developers ;->

Let's just use two digit years everywhere. No one's going to be using our software after 1999!

being a perfectionist i would go here for 150 :D

as low as the chances are, people have passed the 120, and who know what shall happens in the coming 30 years :D

i don't find it that important however..

It all depends on the application. A line of business (LOB) application for order processing is very different to tracking historical or future data.

One can agree it needs to be a valid date, but consider there are multiple calendars (e.g. month number can be 13, year can be over 5000).

Validate for an integer and to be helpful; I think anything else: an abusive/big brother/over-enginereed system is a bad idea.

People should be allowed to lie on these forms if they wish; it's not a legal thing, it's a website.

Don't take it so seriously.

Just let the user pick a date. The user should be in control..not the system/developer. The only date you should avoid with respect to DOB is the future as that is incorrect (i.e. preventing error by design). The date picker you provide should handle any date format issues.

And definitely do not throw up any cheeky exceptions/messages. Your message should aid the user in recognising & recoverying from an error.

Hope that helps.

Below are the checks that you can do while validating the DOB:

calculate the age from the DOB and do the following checks

AGE > XX [XX is the min age required to apply]

AGE < XX {SHould throw a message mentioning that you are not old enough}

AGE = XX

If there is no upper limit of age then we can take it as retirement age else verify with the upper limit for the next two checks

AGE < Retirement Age

AGE > Retirement Age {Should throw a message mentiong that you are too old to apply}

AGE = retirement Age

DOB is a valid date (by giving valid date)

DOB is invalid -

Enter 0 in either of day/month/Year

Enter some negative Value

Enter some invalid date e.g. 30th feb or 32 Jan etc

Enter valid date with different separators (although the date is a valid one but due to different separators it will become an invalid one)

Enter date with different formats such as by giving dd/mm/yyyy, dd/mm/yy, dd/MON/yyyy etc.

Enter some future date (Invalid here as your purpose is something different)