Should Humans Be Called Ape2?

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.

TimeZone2 comes to replace TimeZone in order to support Vista's Dynamic Time Zone APIs and offer some other new functionality.
According to Krzysztof, the team had several options:

  1. Deprecate the current TimeZone using ObsoleteAttribute and use the same type for the new functionality, but this, according to Krzysztof, will simply not happen.
  2. Use a new namespace, but this will cause confusion, since the type name would have to be fully qualified.
  3. Find a better name, yet no one has been able to come up with one that would satisfy the team.
  4. 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.]


9 thoughts on “Should Humans Be Called Ape2?

  1. I would tend to lean towards the break camp, but I think the thing that really muddies the issue is the fact thet .Net Framwork 3.0 is not really a “Major Version”, its 2.0 with version 1 of some Major extensions.

  2. That’s another decision I don’t get, but since it’s already been decided and doesn’t bother me that much, I’ll use it for the good of the discussion.

  3. While I am not found of the name, it does not bother me that much. What do you do done the line when the next version comes out? TimeZoneExEx? How long does that continue?
    I am not happy with the current TimeZone or new TimeZone2 classes, and especially dislike the design of DateTime. I want to replace them, but Microsoft has sealed the classes and will not provide an interface.
    I am all for breaking changes when the original is poorly designed and / or to be replaced. A developer should not blindly assume that their application will run, untested, on a new version. I support a breaking change here; however, there are so many other more important types that need to be fixed as well. TimeZone is not very high on my priority list, but it would be a good start.

  4. I agree with you Omer. TimeZone2 is a mistake and opens the door to terrible Win32-like naming conventions just like you said.
    Is there any way to make a difference in this decision? Any blog where I can post a comment and hopefully be noted by the actual developers?

  5. I agree, TimeZone2 is horrible
    If it deals with Dynamic Time Zones – just call it DynamicTimeZone..?!?
    by the way regarding the post title – some people would probably only qualify as Ape 0.5 – but that’s another story :)

  6. yeah and how many of you complained about X509Certificate2?
    there is nothing wrong with this as long as we can expect retirement on the third cycle. to that end i would like to see for instance the plans for .net 4 to reintroduce TimeZone as a derivative of TimeZone2 and then to deprecate Timezone2 with warnings.
    by 5 TimeZone2 should be deprecated with errors and TimeZone codebase should become entirely that of TimeZone2.
    it is well known that .net 2 is versioned at the assembly level. to have an improved version of a class named .net 2 doesn’t look as nice but not every change shoudl require a new assembly! as for DynamicTimeZone that is useless – its the same as TimeZone2 but harder to find. Next we’ll have BritishTimeZone and USTimeZone and CustomTimeZone and you’ll think they are ok – just because they have a longer name.
    The classNameN principle works extremely well to convey a step forward. dynamictimezone conveys no such hint.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s