Yeah.. Krzysztof have finally blogged about the controversial naming guidelines around TimeZone2!

Check it out: http://blogs.msdn.com/kcwalina/archive/2006/10/06/TimeZone2Naming.aspx

Also, I'd like to repost one of my responses to the names suggested:

TimeZoneExtended:

If we were to call it "TimeZoneExtended", why dont we just call it "TimeZoneEx"?
Again.. Page 47 of the .NET Design Guidelines:
"DO NOT use the "Ex" (or similar) suffix for an identifier to distinguish it from an earlier version of the same API."

Also, I know I am quoting the guidelines a lot. I am not saying because the guideline say so... therefore we're doing it this way. But these are the guidelines te BCL team came up, and as the BCL team, we strongly believe the guidelines will help us create a more consistent framework.

TimeZoneData:

The .NET Framework actually doesn't store any time zone data. We use the OS's data. So calling the class as such is misleading.

TimeZoneInformation:

Too long. :( This is a core type.

TimeZoneDynamicSupport:

Doesn't have built in Dynamic Time Zone support if your OS doesn't have it, because we rely on the OS to give us the Dynamic Time Zone data. If you create a TimeZone2 object, it can have Dynamic Time Zone support though. This may be confusing the normal user who expects it to have Dynamic Time Zone support at all times. Also, this is too long.

TimeZoneVistaCompatible:

It is not *just* Vista compatible. It is compatible with Vista and beyond. Plus, it works on XP as well. This will be misleading to users, plus it is too long.

TimeZoneUseThisOneTheOldOneIsStupid:

Hey, that's what TimeZone2 is suppose to communicate, but in a much shorter way. :)

Remember, I discuss the principles of naming an API here. For the BCL team, short is VERY important. When Anders review our API naming, length of name is one of the things he is concern about.