If you ever take a step back from what you're doing it can sometimes seem pretty abstract. Here's an example. I was looking at an issue in an app that I was supporting. The problem concerned a field which was to store a date value. Let's call it, for the sake of argument,
valuation_date. (Clearly in reality the field name was entirely different... Probably.) This field was supposed to represent a specific date, like June 15th 2012 or 19th August 2014. To be clear, a date and *not* in any way, a time.
valuation_date was stored in a SQL database as a
<a href="http://msdn.microsoft.com/en-gb/library/ms187819.aspx">datetime</a>. That's right a date with a time portion. I've encountered this sort of scenario many times on systems I've inherited. Although there is a
<a href="http://msdn.microsoft.com/en-gb/library/bb630352.aspx">date</a> type in SQL it's pretty rarely used. I think it only shipped in SQL Server with 2008 which may go some way to explaining this. Anyway, I digress...
valuation_date was read into a field in a C# application called
ValuationDate which was of type
valuationDate which had the type
You can probably guess where I'm going with this... Despite our (cough) rock solid naming convention, the situation had arisen where actual datetimes had snuck in. That's right, in the wilds of production, records with
valuation_dates with time components had been spotted. My mission was to hunt them, kill them and stop them reproducing...
Dates is a sticky topic in many languages. As I mentioned, SQL Server has a
<a href="http://msdn.microsoft.com/en-gb/library/bb630352.aspx">date</a> data type. C# has
<a href="http://msdn.microsoft.com/en-gb/library/system.datetime.aspx">DateTime</a>. If you want to operate on Dates alone then you're best off talking looking at Jon Skeet's NodaTime - though most people start with
Date - but
<a href="http://momentjs.com/">Moment.js</a> may help.
My point is that it is a long standing issue in the development world. We represent data in types that aren't entirely meant for the purpose that they are used. It's not just restricted to dates, numbers have a comparable story around the issue of decimals and doubles. As a result of data type issues, developers experience problems. Like the one I was facing.
But we didn't want to get bitten again. We wanted ourselves a little belts and braces. What do do? Hang on a minute, lads – I've got a great idea... It's
<a href="http://msdn.microsoft.com/en-us/library/system.componentmodel.dataannotations.validationattribute(v=vs.110).aspx">ValidationAttribute</a> time!
We whipped ourselves up an attribute that looked like this:
This attribute does 2 things:
- Most importantly it fails validation for any
DateTime?that includes a time portion. It only allows through DateTimes where the clock strikes midnight. It's optimised for Cinderella.
- It fails validation if the attribute is applied to any property which is not a
You can decorate
DateTime? properties on your model with this attribute like so:
And if you're using MVC (or anything that makes use of the validation data annotations) then you'll now find that you are nicely protected from DateTimes masquerading as dates. Should they show up you'll find that
ModelState.IsValid is false and you can kick them to the curb with alacrity!