Welcome to MSDN Blogs Sign in | Join | Help

Kathy Kam

Reflection on the CLR and .NET
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

Posted: Thursday, September 28, 2006 6:30 PM by KathyKam

Comments

ShadowChaser said:

I think it's a good idea, but *please* think of a better name than "TimeZone2"!
# September 28, 2006 10:03 PM

KathyKam said:

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. :)
# September 28, 2006 10:18 PM

@ Head said:

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

Charles Bocock said:

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.
# September 29, 2006 9:44 AM

RubenP said:

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?
# September 29, 2006 4:44 PM

KathyKam said:

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...
# September 29, 2006 5:06 PM

RubenP said:

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?
# September 30, 2006 4:37 PM

KathyKam said:

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.
# October 1, 2006 3:27 AM

Michael Teper said:

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!
# October 9, 2006 3:49 PM

KathyKam said:

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

# October 9, 2006 5:01 PM

Omer van Kloeten's .NET Zen said:

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

# October 10, 2006 4:17 PM

Commerce Team Blog said:

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

# December 12, 2006 8:20 PM

Stephen (Sly) Gryphon said:

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

# December 15, 2006 11:48 PM

ColeDosa said:

Ok, stay alert! Hold your breath!

...

Call it DynamicTimeZone or TimeZoneDynamic. But not 2.

# March 26, 2007 11:41 AM
Leave a Comment

(required) 

(required) 

(optional)

(required) 

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Page view tracker