Bye bye "System.TimeZone2", Hello "System.TimeZoneInfo"

Did I catch your attention? I know I haven't posted anything interesting in a while. I am currently working on a project that is unannouced.

However, I want to let everyone know that in Orcas Beta1, that will be release in a few months, the BCL team decided to rename this new type to "System.TimeZoneInfo". This should come as no surprise to my regular readers. We got a lot of feedback on Krzsyztof's blog, the BCL blog, my blog and the BCL Feedback about the name.

 Though personally, I find that System.TimeZone2 clearly indicates to a new .NET users that System.TimeZone is basically obsolete. I do agree with everyone's feedback that using numeric modifier is not scalable in the long term. It is a tough call, but given the incredible amount of feedback we got. It looks like System.TimeZoneInfo would be a better name. My only hope is that I don't get another flood of feedback from people who loved the System.TimeZone2 name and System.TimeZoneInfo.

We do value your feedback. So, what do you think?

Comments (14)
  1. Mathias Holmgren says:

    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.

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

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

  4. Greg D says:

    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.  

  5. says:

    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".

  6. chyld says:

    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.


  7. says:

    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.

  8. chronos says:

    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.

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


  10. Joe Healy says:

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

  11. David Nelson says:

    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.

  12. Speedbird186 says:

    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]

  13. Memmorium says:

         Good idea!

    P.S. A U realy girl?

  14. says:

    TimeZoneInfo appears to have a but when returning the .Id property for the Israel timezone.

    TimeZoneInfo.Local.Id = "Jerusalem Standard Time"

    TimeZoneInfo.GetSystemTimeZones()[14].Id = "Israel Standard Time"

Comments are closed.

Skip to main content