Consider the following 2 scenarios: Scenario 1). Today is May 1st 2012, and Scenario 2). Today is September 1st 2012.
Now, consider that we write on our webpage the
What you are looking for is indeed not what TimeSpan represents. TimeSpan represents an interval as a count of ticks, without respect to a base DateTime or Calendar.
A new DateDifference type might make more sense here, with a constructor or factory method taking a base DateTime, a target DateTime, and optionally a Calendar (defaulting to CultureInfo.CurrentCulture) with which to compute the various difference components (years, months, etc.)
EDIT: It looks to me like Noda Time may have the tools you need for this — the Period class "[r]epresents a period of time expressed in human chronological terms: hours, days, weeks, months and so on", and in particular Period.Between(then, now, PeriodUnits.AllUnits) seems to be the precise calculation you're asking for — but it's necessarily a much more complex class than TimeSpan. The Key Concepts page on the Noda Time wiki explains how "humans make time messy":
Leaving aside the tricky bits of astronomy and relativity, mankind has still made time hard to negotiate. If we all used ticks from the Unix epoch to talk about time, there wouldn't be a need for a library like Noda Time.
But no, we like to talk in years, months, days, weeks - and for some reason we like 12pm (which confusingly comes before 1pm) to be roughly the time at which the sun is highest... so we have time zones.
Not only that, but we don't all agree on how many months there are. Different civilizations have come up with different ways of splitting up the year, and different numbers for the years to start with. These are calendar systems.