Ever since Kathy Kam announced on her weblog that a new type named TimeZone2 will be introduced into the Orcas release of .NET, the community has been in an uproar, claiming the new name is horrible and that we're going back to the days of Win32 and COM with types like TimeZone3 and DateTimeEx not far down the line.
- Deprecate the current TimeZone using ObsoleteAttribute and use the same type for the new functionality, but this, according to Krzysztof, will simply not happen.
- Use a new namespace, but this will cause confusion, since the type name would have to be fully qualified.
- Find a better name, yet no one has been able to come up with one that would satisfy the team.
- Call it TimeZone2.
Unfortunately, they decided on the last option, backed by an invocation of a Design Guideline (And none other than one of the very few guidelines I wholeheartedly disagree with).
I, personally, am with the Break Camp: Simply take the old functionality and deprecate it or just remove it altogether. The Orcas framework is to be released at version 3.* (a change of the major version since the last release), which means to users that breaking changes are acceptable and even expected. I have never heard known of a single serious software developer that has taken for granted that their applications will simply work when moving from .NET 1.0 to .NET 2.0 and I don't think I'll ever hear of one blindly moving to .NET 3.0.
Want to make it easier on your customers? Create an automatic tool (maybe as part of Visual Studio Orcas) that translates current behaviour to 3.0 behaviour.
Invoking the Red-Bits-In-Place-Service-Pack excuse is moot here, since it was the wrong call to make in the first place. Backwards compatability is not the Holy Grail.
This is the very first step on the road to making the .NET Framework an unusable patch-work. Just imagine a developer new to .NET which starts with version 3.0 and sees TimeZone and TimeZone2.
The CLR Team's posts about this in chronological order:
Orcas September CTP available… Hello "System.TimeZone2"!
System.TimeZone2 Starter Guide [Kathy Kam]
Designing System.TimeZone2 – Part 1 (API naming and new class or not)
Designing System.TimeZone2 – Part 2 (Dynamic Time Zone support)
System.TimeZone2 Naming … and related design guidelines
Naming Guideline Discussion
When there is no good name…
[Update: The team went back to the whiteboard and renamed it TimeZoneInfo.]