Orcas September CTP available… Hello "System.TimeZone2"!


I am so excited that the CTP is finally available! As soon as you crack open the bits, you’ll find what I have been working months on! Can you guess what it is???


NET Framework improvements such as:



  • New managed add-in model enables developers to add a version-resilient extensibility model to their products.
  • Support for time zone conversion, enumeration and serialization, including cases where Daylight Saving Time rules change over time.
  • Reflection in Partial Trust, enabling sand box scenarios for all applications that depend on these features.
  • The ability to control the garbage collector’s latency mode
  • Improved CLR ThreadPool micro-performance and throughput for worker and IO completion

The class that have those functionality is System.TimeZone2. I will be posting some samples and quick guide on the BCL team blog probably next Tuesday. For my loyal readers here… I’ll treat you wit the most basic sample on how to convert a DateTime with this new class right now!!! This example converts a DateTime from my home town “Sydney, Australia” to “Redmond, WA, USA”.


 



void BasicConvertScenarios()


{


    DateTime newTime;


    DateTime currentDateTime = GetUserDateTime();


    string ausTimeZoneId = “AUS Eastern Standard Time”;


    string pstSystemId = “Pacific Standard Time”;


    newTime = TimeZone2.ConvertTimeBySystemTimeZoneId(userDateTime,


                                              ausTimeZoneId,


                                        pstSystemId);


}


 


 


I am so excited! Let me know what you think! People have been asking for this so much… I hope their needs are met!


 


The CTP is available here: http://www.microsoft.com/downloads/details.aspx?FamilyID=82243606-d16d-445c-8949-9ee8c10cda2e&DisplayLang=en

Comments (15)

  1. ShadowChaser says:

    I think it’s a good idea, but *please* think of a better name than "TimeZone2"!

  2. KathyKam says:

    Oh I knew that would come up! haha… didn’t I say 2 post ago that naming an API may be one of the hardest thing. Well, according to the .Net Framework Design Guidelines, if you want to completely replace a prevous type, you should name it “<previousType>2”.

    So, this is the most “correct” name for this type. Also the shortest and clearest. :)

  3. @ Head says:

    while I&amp;#39;m waiting for the huge Orcas images to download , I thought I&amp;#39;d catch up on some blog

  4. Charles Bocock says:

    I like it. It’s better than TimeZoneEx.

    Can’t wait for TimeZone3 😉

    Now, if you can just get the SQL Server guys to have a base type like this, then my life would be almost complete.

  5. RubenP says:

    Okay, so you’re replacing TimeZone, hence the 2. But why are you replacing this class? Besides, this sample shows a static method, that does nothing that couldn’t be done with a real implementation of TimeZone in the first plase.

    And I see you’ve chosen to take the route of US-centric English names for ‘ID’s. Yuck. There are standards and conventions for stuff like this, you know. I can only pray these are not localizable names.

    Not a nice teaser at all.

    I haven’t got time (or the bandwidth) to download 3 Gigs, so where can I find some online docs in the meanwhile?

  6. KathyKam says:

    We decided to replace the class after weighing in various aspects. e.g. amount of breaking changes needed if we simply augmented the exisiting System.TimeZone class.

    Right now, I am the only person generating any sort of samples or docs for the new class. Our UE team is busy preparing to generate more docs. Stay tune for my post on the BCL team. :)

    P.S. regarding the "US-centric English names for IDs", well.. there are no standards nor convention for stuff like this actually. We’ve worked closely with the Windows team on it. I’ll explain where the IDs are from in my BCL post. But to answer your quick question, IDs are not localizable. DisplayNames are though…

  7. RubenP says:

    Well, there are existing time zone systems and conventions in use. Especially the zoneinfo or tz database. Which is only used by Unix, Mac OSX, glibc, Java, etc… This feels like a clasic case of the Not Invented Here syndrome.

    Just another two questions: what’s your update policy? And do you record the changes that occur from year to year in various regions, so the TZ conversions for US timezones in say 2005 are still valid when I try to make them in 2007?

  8. KathyKam says:

    We do not actually own the data. Our time zone conversation will use data from the OS. Therefore, Microsoft has a uniformed update policy for this.

    Vista has added support for dynamic time zone. Therefore, time zone in 2005 will stay valid when you make them in 2007. However, currently, XP does not support that. Windows is looking into how we should add that functionality to XP.

  9. Just one question: why not just use the OS index that’s been there for ages in the registry for ID instead of the string? Storing the long string as an identifier in the DB is … icky!

  10. KathyKam says:

    Vista has deprecated the "index" value. So we cannot use it.

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

  12. The different systems in Commerce Server take somewhat different approaches for how they store DateTime

  13. Stephen (Sly) Gryphon says:

    "P.S. regarding the ‘US-centric English names for IDs’, well.. there are no standards nor convention for stuff like this actually."

    Actually, there is — the Unicode CLDR (Locale) data. In fact, the CLDR standard data is already used for Globalization.RegionInfo and Globalization.CultureInfo within the Framework. So, rather than no standard, there is a standard already partially implemented in the .NET Framework!

    For example, the CultureAndRegionInfoBuilder.CreateFromLdml() method. The MSDN documentation even refers to the standard "For more information about the LDML standard, see Unicode Technical Standard #35, ‘Locale Data Markup Language (LDML),’ at the Unicode home site."

    Better still, the CLDR homepage mentions "LDML is a format used not only for CLDR, but also for general interchange of locale data, such as in Microsoft’s .NET.".

    And there’s more… the CLDR data even includes mapping information to map to the Microsoft names! The mapping for the two values in the example above are "America/Los_Angeles" and "Australia/Sydney".

    Maybe some better communication within Microsoft, and you would know that you had already implemented part of this standard!

    Note: The CLDR names are the same as those used in the zoneinfo/tz database, so would provide interoperability with unix, Java, etc. e.g. for passing user timezone preferences in an interoperable webservice.

    For more information you can see http://www.unicode.org/cldr/.

    In the future, please do a bit more research to check whether there is a standard or not before claiming it does not exist (especially when the standard is already used by Microsoft).

  14. ColeDosa says:

    Ok, stay alert! Hold your breath!

    Call it DynamicTimeZone or TimeZoneDynamic. But not 2.