Fervent Coder

Coding Towards Utopia...by Rob Reynolds
posts - 278 , comments - 431 , trackbacks - 0

My Links

News


Rob Reynolds

Subscribe to Fervent Coder RSS
Subscribe to Fervent Coder by Email

About Me

I manage several open source projects. Need...
   ...package management for Windows?
   ...automated builds?
   ...database change management (migrations)?
   ...your application to check email?
   ...a monitoring utility?

I also write for



Like what you are reading? Want to buy me a cup of coffee?
PayPal - The safer, easier way to pay online!

Archives

Image Galleries

Sites

Always Use Nullables for Dates Follow-up

I have always wondered why you can't have an "empty" date in VB and C#.

I had some good feedback on my recent post on nullable dates and I wanted to clarify why I think nullables are great for dates.

The point I am trying to get across is that with dates, in a business sense, you either have a date or you don't. You never really have a 01/01/0001. Using 01/01/0001 or 01/01/1753 is a hack for lack of being able to say that you have an empty date.

I am going to make a quick comment on strings. Strings are nullable.  You make a check to see if they are null and/or if they are empty strings. It seems like you have two things you need to do with strings a lot. What I like about strings in the CLR is that Microsoft allows you to check both at the same time with the static IsNullOrEmpty function.

string d = null;
if (!string.IsNullOrEmpty(d))
{
    //do something
}

Notice it is one call that checks for both baked right into the string class. Plus it's a good programming practice to ensure a non-null value in the first place before using items and/or calling methods, properties, etc. on them.

Now back to the matter at hand: nullables. I am not concerned really with using nullables with other types besides DateTime. I would say for the most part there are arguments for and against nullables of other types (int, decimal, etc). Those I would say to use where appropriate (if appropriate). A lot of times an empty value is the same as no value.  9 times out of ten if you are using an integer, 0 is going to be appropriate for both 0 and for absence of a value (null).

With persistence you are saving that no value or empty value to a database, file, log, etc.  Let's say database since that is the most popular form of persistence.  You are saving that empty value to it.

But with dates it's different. There is no empty date. What is this date logic crap? If I have a date less than some arbitrary value, I don't want to save it to my database. I have to implement that logic. What happens in my objects when I pull a null ("empty") date field from a database? Will I get an arbitrary date in that field suddenly or do I get null? What happens if I re-persist it? Does it stay null? How much logic is there to check to see if the date is below some arbitrary value before you decide whether to persist it or not?

From the beginning of my development career I have always wondered why you can't have an "empty" date in VB and C#. Why do you have to check it's value differently than other types? Why is date logic a bane? Why can't you just have an empty date?

That's where nullables come in. You can have an "empty" date and the logic gets very simple.  That is why I say always use nullables for dates. Unless you like pain. ;D

Print | posted on Friday, August 8, 2008 7:04 PM | Filed Under [ Code ]

Feedback

Gravatar

# re: Always Use Nullables for Dates Follow-up

Nice follow-up. The biggest problem I had with "empty" dates is that we used to use DateTime.MinValue to represent the fact that the user hadn't entered a date. The problem with that is: C#'s DateTime.MinValue (01/01/0001) is not an allowable datetime value in SQL Server (Thanks MS), so we always had to convert to SQL Server's minimum Value (01/01/1753). Thank God we weren't creating any historical archiving applications!

~Lee
8/9/2008 1:27 AM | Lee Brandt
Comments have been closed on this topic.

Powered by: