Thanks very much to those who have posted feedback on this issue:
This reply to the feedback got quite lengthy, so I started a new entry on it.
>> "You COULD have seen and SHOULD have seen this"
We would definitely agree that this is a bad situation and we should have seen this in the first version of the product. The toughest bit is that for the V1.0 and V1.1 products, it is hard for us to even provide good guidelines for completely reliable DateTime scenarios. Although there is dissatisfaction that the currently Whidbey plan is sufficient, it does at least allow for guidelines to be created that can actually be followed.
Three replies emphatically ask that we consider adding a complete new DateTime type in Whidbey that is UTC internally. It is probably worth sharing some of the existing discussion on this point.
Once the full extent of the DateTime problems were understood, a great many options for correcting it were considered. These included changing the implementation to be UTC internally and deprecating the existing data type and replacing it with a completely new one.
It sounds like people are bought into the notion that retroactively changing the internal implementation of the current DateTime to always be UTC and also staying sufficiently compatible accross versions is not possible. This option was thoroughly explored and was a plan of record for a brief time until all the compatibility issues with it were fully explored.
Another option explored was switching over every API that returned a Local instance to returning a UTC instance. Of the 84 APIs that took or returned DateTime in the V1.0 NDP, this would have involved deprecating 81 of them, and replacing them with versions that had an identical signature, but a DateTime instance that was UTC instead of local. This would have created a lot of disruption to owners and consumers of the APIs alike. We would need a very good reason to do this. It was seen as preferable if there was a way allow people to get reliable behavior without having to switch every call involving a DateTime over to using a different API.
This lead to the current plan of record, which is compatible enough to allow existing APIs to get the extra reliability without needing to change either the signature or meaning of their results.
The option of deprecating DateTime and replacing it has many of the same undesirable consequences. More than just deprecating the type istelf, you are then making every API that takes or returns the API obsolete and making it a requirement to switch over to somthing new. We could do this, but we would need a very good reason and a lot of lead time. Given that it was possible to solve the key reliability problem by just making the Local->UTC conversion non-lossy, this was seen a better alternative.
It is suggested that there is still time in Whidbey to add a new DateTime. Actually, there probably is enough time to add such a new type. However, I could get it to you even more quickly by sending you a sample, and it would be no less useful. The reason is that while there may be time to add this new data type, there is not the time to integrate it anywhere near as deeply as you would want. You would need to integrate it with Remoting, Serialization, XML Serialization, the Debugger, XML Convert, Type Converters, etc. etc. You would also want to add several hundred new APIs in technologies like ASP.NET and System.Net to provide versions of their APIs that would accept this new type. There is not enough time to get this level of integration with the rest of the product, so if we did add this type, it would not be of much more use than some sample code.
Given the cost of actually trying to replace something as widely used as DateTime, it is not even clear if it is a good option long term. Part of the value of the .NET Framework is the standardization and simplicity in having, for example, just one way to represent a string. A 2nd DateTime type would erode that and would need a very compelling reason to exist.
A more likely option is that there might be a sort of supplemental time type that is not destined to replace DateTime, but to interoperate well with it, and to be recommended for scenerios where you are doing cross-time-zone stuff. Part of the problem here also is that this is tied to another large work item, which is time zone enumeration. This is quite an expensive work item for us, as outlined in the DateTime FAQ: http://www.gotdotnet.com/team/clr/bcl/TechArticles/techarticles/DateTimeFAQ/FAQ.aspx
This will probably sound defensive and adverserial. Believe me, I don't see this as a good situation and I have actually asked all these same questions you are asking now many times, and we have tried to thoroughly explore them all. But we do feel that the current solution for Whidbey draws the best line between fixing unreliable usage, maintaining compatability across versions and keeping the framework simple and consistent.
I look forward to further discussion of this issue.