Share via

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

  • Article

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: https://www.microsoft.com/downloads/details.aspx?FamilyID=82243606-d16d-445c-8949-9ee8c10cda2e&DisplayLang=en

Comments

  • Anonymous
    September 28, 2006
    I think it's a good idea, but please think of a better name than "TimeZone2"!

  • Anonymous
    September 28, 2006
    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. :)

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

  • Anonymous
    September 29, 2006
    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.

  • Anonymous
    September 29, 2006
    The comment has been removed

  • Anonymous
    September 29, 2006
    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...

  • Anonymous
    September 30, 2006
    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?

  • Anonymous
    September 30, 2006
    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.

  • Anonymous
    October 09, 2006
    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!

  • Anonymous
    October 09, 2006
    Vista has deprecated the "index" value. So we cannot use it.

  • Anonymous
    October 10, 2006
    Ever since Kathy Kam announced on her weblog that a new type named TimeZone2 will be introduced into

  • Anonymous
    December 12, 2006
    The different systems in Commerce Server take somewhat different approaches for how they store DateTime

  • Anonymous
    December 15, 2006
    The comment has been removed

  • Anonymous
    March 26, 2007
    Ok, stay alert! Hold your breath! ... Call it DynamicTimeZone or TimeZoneDynamic. But not 2.

  • Anonymous
    June 01, 2009
    PingBack from http://uniformstores.info/story.php?id=19316