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: 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&#39;m waiting for the huge Orcas images to download , I thought I&#39;d catch up on some blogAnonymous
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 removedAnonymous
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 intoAnonymous
December 12, 2006
The different systems in Commerce Server take somewhat different approaches for how they store DateTimeAnonymous
December 15, 2006
The comment has been removedAnonymous
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