DateTime woes and "The Pit of Failure"...

Having had my own struggles with DateTime parsing, I completely concur with the comments from my peers as they replied to Brad Abrams and the BCL team on the past, present, and future of DateTime processing in the .NET Framework.

The current situation is painful, and unfortunately the future plans for DateTime fail the test for good API design.  This sounds much more like designing for “The Pit of Failure“ than “The Pit of Success“ [quote from Rico Mariani via Brad's earlier post].   API's should be designed so that “developers just fall into doing the right thing”.

I think the best way to assure that the problems are rectified is to create a new DateTime struct or fix the current one (and break backwards compatibility).  Obviously the latter option is much less desireable.

The current plan for VisualStudio.NET 2005 “Whidbey“ is a poor compromise.  One that will only result in every developer creating a set of DateTime helper classes just to remove the pain from correct DateTime manipulation.  Anytime that happens, I consider it a failure of the BCL Team....perhaps harsh, but nonetheless I believe it is true. 

Do we really need to start work on a “DateTime Application Block“?