Kathy Kam

I think the new name is fine. The other FooInfo classes are pretty expressive and when you see one of those you know you are supposed to use it. Since you will add a bunch of stuff I think that association hints in the right direction in this case.

I have a slightly different question. When, if ever, would you consider using the ObsoleteAttribute when doing class library/framework development? Please explain why and the tradeoffs.

Ever since Kathy Kam announced on her weblog that a new type named TimeZone2 will be introduced into

Just wanted to say: Woohoo! Sanity prevails...

I like TimeZoneInfo more, that's the right way to go.  In my own, personal, opinion, the right places to indicate that it supercedes System.TimeZone are in the System.TimeZone documentation and the System.TimeZoneInfo documentation.  

The problem I see with "TimeZoneInfo" is what happens if you need to obsolete it and introduce yet another type in the future?  There's not a clear versioning path for future versions with the "-Info" suffix; and other than the ObsoleteAttribute, it's not immediately obvious which is the preferred type.  It's not even immediately obvious that "TimeZone" and "TimeZoneInfo" are two versions of the same thing.

The "-2" suffix, while admittedly looking a little out of place, makes it blatantly clear that it's newer and preferred over the non-suffixed type -- and when using Intellisense, is guaranteed to show up right below the obsolete type, making it quickly discoverable for anyone about to use the older type.

Both solutions obviously have pros and cons, neither is an elegant silver bullet solution, but given the choice, I'd cast my vote in favor of "-2".

I second what tfries said...when intellisense pops up, it is immediately obvious that TimeZone2 is a newer rev than TimeZone.  Whereas TimeZoneInfo...well...upon initial inspection I have no idea how that would differ from TimeZone.  My suggestion is to keep it TimeZone2.

-Chyld

Good choice. Moreover, the name TimeZoneInfo is better too: the object itself isn't a time zone, it just provides operations and information for working with time zones, and it fits in nicely with existing Infos like CultureInfo.

Intellisense is a non-issue. This class will be part of a library that will be used in a variety of text editors, none of which have Intellisense except for Visual Studio.

While I think that TimeZone2 is not a great name, it is immediately understandable that it replaces TimeZone. I do not get that same understanding from the name TimeZoneInfo. Thus, it is important that the documentation appropriately describes the situation. Also, if it really does supersede TimeZone, then ObsoleteAttribute it.

[Off topic]

Several months ago I and others talked about a UTC-only DateTime class. If Microsoft will not create it, please enable others to implement it by either unsealing DateTime and / or making DateTime implement an IDateTime interface and updating signatures to use the interface.

http://blogs.msdn.com/kathykam/archive/2006/10/05/Designing-System.TimeZone2-_2D00_-Part-2-_2800_Dynamic-Time-Zone-support_2900_.aspx

When you said the beta 1 is going to be released ?

Thanks

Can you give us a post on exactly what the new DateTime2 class does?

I responded to several MSDN blogs about the disadvantages of naming it TimeZone2 before I discovered that the name has already been changed :) I do agree with tfries that you might have a progression problem with Info; however, I do not believe that problem is any worse than the problems with the 2 suffix.

But I would mainly like to say "thank you" to Microsoft for actually listening to the feedback and reversing what was apparently an internally unanimous decision in order to satisfy the community. I participate in the .NET community in a number of ways, including posting suggestions at the feedback center, moderating in the MSDN forums, and reading and commenting on MSDN blogs. Too often I feel like Microsoft takes a "poor little child, let me explain why we are always right and you are always wrong" attitude when confronted with opposition to its design decisions. I am glad that, on this issue at least, that was not the case.

This is thoroughly confusing to me. At first, you go through great lengths explaining why TimeZone2 is the correct class name -- according to the BCL guidelines. By the way: your arguments convinced me... TimeZone2 is definitely much clearer.

What is the justification for deviating from the BCL guidelines? How does Anders feel about this?

If enough people beg loud and long enough, will it be changed back to TimeZone2? [I don't see how "listening" to feedback is a valid argument to change a class name... people who don't like a name are much more likely to speak up and cast a vote for a new name than are those who agree with the existing name]

     Good idea!

P.S. A U realy girl?