Mark Needham

Thoughts on Software Development

C#: Wrapping DateTime

with 5 comments

I think it was Darren Hobbs who first introduced me to the idea of wrapping dates in our system to describe what that date actually means in our context, and after suffering the pain of passing some unwrapped dates around our code I think I can safely say that wrapping them is the way to go.

The culprit was a date of birth which was sometimes being created from user input and sometimes being retrieved from another system.

The initial (incorrect) assumption was that we would be passing around the date in the same string format and there was no point wrapping the value as we were never doing anything with the data.

It proved to be a bit of a nightmare trying to work out which state the data of birth was in various parts of the application and we ended up doing conversions to the wrong format and then undoing those and losing the formatting in other places!

Step 1 here was clearly not to pass around the date as a string but instead to convert it to a DateTime as soon as possible.

This is much more expressive but we can take this one step further by wrapping that date time in a DateOfBirth class.

public class DateOfBirth 
{
	private DateTime? dateOfBirth
 
	public DateOfBirth(DateTime? dateOfBirth) 
	{
		this.dateOfBirth = dateofBirth;
	}
 
	public string ToDisplayFormat()
	{
		return dateOfBirth == null ? "" : dateOfBirth.Value.ToString("dd MMM yyyy");
	}
}

When we want to display this object on the page we just have to call the ToDisplayFormat() and if that date format needs to change then we have only one place to make that change. Creating this class removed at least 3 or 4 ‘DateTime.Parse(…)’ and ‘DateTime.ToString(…)’ calls throughout the code.

Now we could achieve the same functionality using an extension method on DateTime? but it’s not as expressive as this in my opinion. It is also really obvious when looking at the code to know what type we are dealing with and it is really obvious when reading this class which method we will use to get the format to display to the user.

I will certainly be looking to wrap any DateTimes I come across in future.

Be Sociable, Share!

Written by Mark Needham

February 25th, 2009 at 11:12 pm

Posted in .NET

Tagged with ,

  • That certainly is handy, did you consider adding a constructor overload to parse the string value? Also, I think overriding ToString rather than using ToDisplayFormat might save you a method call here and there.

  • Cool idea regarding constructor overload.

    We’ve actually been discussing what ToString is for and the consensus seems to be that it is more used as a debugging tool these days rather than as a way of creating a display representation of an object.

    Also I guess we can be a bit more expressive about what format we are converting to by writing our own ‘To…’ methods.

  • Jeremy Gray

    @Mark re: ToString – My client project leaned that way too, until it became clear that there was more benefit to be had from using custom formatting methods for things like logging output and leaving our ToString implementations to be the human-readable, UI-friendly versions because it greatly simplifies data binding in a good many cases.

    To each their own, of course. 🙂

  • Pingback: Coding: Using ‘ToString’ at Mark Needham()

  • Pingback: OO: Micro Types at Mark Needham()