Back To Basics - Validating a date
Recently, a lot of my time has been spent working on systems written by someone else. One of the biggest problems I see in these systems is a lack of basic validation. Limiting the length of strings, requiring values and making sure values fall into the allowed range.
The one that annoys me the most is date validation. Let's be clear, I'm talking about some basic rules to make sure that a date is not just a valid date but is a reasonable value for the data element. January 1, 1900 is a valid date except if we're talking about a birth date for living people. The current oldest living person is 116 years old and there aren't that many people over 100. Ask yourself this question, "Are they going to be in my system?" Probably not, so don't allow it.
This simple rule will keep a lot date typos out of your system. Remember, dates come in different formats MM/dd/yyyy or dd/MM/yyyy or yyyy/MM/dd. Some users will enter zeros such as 08/02/1991 while others might enter 8/2/91. We can't eliminate all typos but at least we can get worst ones.
What other rules can we put in place? Here's the two questions you should be asking about any dates in your system.
Let's say we're developing a tracking system for a health screening company. These are the people that make sure you're not already dead or dying when you buy life insurance. They need to capture the applicant's date of birth, date the test was ordered and date the screening was performed. The insurance company only insures people between the ages of 21 and 65.
We can come define some simple rules very quickly.
That's all it took. I would probably look to limit the range on the date the test was ordered because it seems like these should be entered in a timely manner. Maybe six months or a year.
So who is responsible for developing the rules? The project manager? Business analyst? User? The real answer is you, the developer. Why? The short answer is because in the end, it's your code that is going to be blamed.
The real answer is you're the professional. When people hire a professional, they are paying to get someone who is more knowledgeable about the details. They expect someone who is going to think "you cannot have a date of birth in the future in this system." You know the look you're going to get when people discover you can enter a birth date of 02/22/2233.
So if you're working with a date element take the time to make sure you get the answers for two simple questions.
The one that annoys me the most is date validation. Let's be clear, I'm talking about some basic rules to make sure that a date is not just a valid date but is a reasonable value for the data element. January 1, 1900 is a valid date except if we're talking about a birth date for living people. The current oldest living person is 116 years old and there aren't that many people over 100. Ask yourself this question, "Are they going to be in my system?" Probably not, so don't allow it.
This simple rule will keep a lot date typos out of your system. Remember, dates come in different formats MM/dd/yyyy or dd/MM/yyyy or yyyy/MM/dd. Some users will enter zeros such as 08/02/1991 while others might enter 8/2/91. We can't eliminate all typos but at least we can get worst ones.
What other rules can we put in place? Here's the two questions you should be asking about any dates in your system.
- What is the minimum and maximum range?
- Is the date related to some other date that we can use to validate?
Let's say we're developing a tracking system for a health screening company. These are the people that make sure you're not already dead or dying when you buy life insurance. They need to capture the applicant's date of birth, date the test was ordered and date the screening was performed. The insurance company only insures people between the ages of 21 and 65.
We can come define some simple rules very quickly.
- Date of birth must be between the current date minus 65 years and the current date minus 21 years.
- The date test was ordered must be between the date of birth and the current date.
- The date of screening must be between the date the test was ordered and the current date.
That's all it took. I would probably look to limit the range on the date the test was ordered because it seems like these should be entered in a timely manner. Maybe six months or a year.
So who is responsible for developing the rules? The project manager? Business analyst? User? The real answer is you, the developer. Why? The short answer is because in the end, it's your code that is going to be blamed.
The real answer is you're the professional. When people hire a professional, they are paying to get someone who is more knowledgeable about the details. They expect someone who is going to think "you cannot have a date of birth in the future in this system." You know the look you're going to get when people discover you can enter a birth date of 02/22/2233.
Comments