System.TimeZone2 Starter Guide [Kathy Kam]

System.TimeZone2 Starter Guide is now posted!

Kathy Kam — Tue, 03 Oct 2006 20:46:52 GMT

I have posted my starter guide on the BCL team blog ! I'll post a follow up and advance usage here. :)

re: System.TimeZone2 Starter Guide [Kathy Kam]

TheMuuj — Tue, 03 Oct 2006 21:49:15 GMT

While I agree that this functionality is needed, I'm disappointed in both the name of the class and the namespace it was put in.

Since System.TimeZone is taken, why not just create a System.Globalization.TimeZone and mark the original one obsolete?

Do we need to be polluting the System namespace any more? Also, do we really want to resort to the class numbering? That's worse than "TimeZoneEx."

re: System.TimeZone2 Starter Guide [Kathy Kam]

KathyKam — Tue, 03 Oct 2006 22:00:07 GMT

Hi, TheMuuj,

I am sorry you are disappointed in the name. According to the .NET Design Guidelines, if we were to obsolete a class and replace it with a new one. The correct way to do it is to name the new class as <class>2. It is unfortunate that we have to do it, but this class is realy a replacement of the exisiting System.TimeZone class. It doesn't belong in System.Globalization.

According to the Design Guidelines:

"Do use a numeric suffix to indicate a new version of an exisiting API if the existing name of the API is the only name that makes sense"

See page 47 in the .NET Design Guidelines for more details.

re: System.TimeZone2 Starter Guide [Kathy Kam]

Thomas Krause — Wed, 04 Oct 2006 00:14:30 GMT

I like this new functionality, but I am also very disappointed by the name change, too. If the .NET Design Guidelines require that, you should change them (after all Microsoft wrote them...). Adding a numeric suffix to the class tells you nothing about the differences between the two classes and is very confusing. What happens if you make another change to the TimeZone class, do we have TimeZone, TimeZone2 and TimeZone3 then? And if the original TimeZone class is finally removed, we are stuck with a TimeZone2 class and nobody knows why it is not simply called TimeZone.

Couldn't you simply add the new members to the existing TimeZone class?

If there is really no way to replace the existing class/name, I would still prefer putting the class in another namespace or giving it a more meaningful name like ExtendedTimeZone (I am sure you can come up with an even better name).

Thanks for listening!

Thomas Krause

re: System.TimeZone2 Starter Guide [Kathy Kam]

Ari Weinstein [BCL] — Wed, 04 Oct 2006 00:31:18 GMT

Thanks Thomas, we actually have the guideline of using numeric suffixes to new types when we expect previous versions will become entirely superseded by new types - and we like the guidance. The reason is in these cases, we do not want the difference between types to be ambiguous. Having a numeric specifier means "only use the newer type from here out." If we called it something like TimeZoneWithConversion, users may decide to use the original TimeZone class in scenarios where they do not plan on doing conversions, but that is not our intent for users with the type.

FYI The "EX" suffix is particularly problematic because then it becomes even more ugly to ship a third type in the rare case that is required.

re: System.TimeZone2 Starter Guide [Kathy Kam]

RubenP — Wed, 04 Oct 2006 01:04:20 GMT

Can't say I like the design. Why TimeZone2.Convert...(timeZone, dateTime) and not timeZone.Convert...(dateTime)?

Further more, until this very moment, you're still holding out on the redesign of TimeZone2. I don't see anything that couldn't be done with TimeZone. Heck, several people (including me), already implemented these features based on the appropriate registry keys using the original TimeZone class.

Or, is the real case you've implemented TimeZone2 (in System.Core.dll rather than System.dll), because you can't touch System.dll? I've seen the term "Red bits" several times, and that Orcas would a .NET 2.0 extension, not upgrade. That would explain a lot, but I'd still like TimeZone2 to be an extension of TimeZone.

re: System.TimeZone2 Starter Guide [Kathy Kam]

KathyKam — Wed, 04 Oct 2006 01:27:29 GMT

Hi Ruben,

timeZone.Convert is ambiguous as to whether you are converting to or from. We decided tat having it as a static method is more clear.

After much consideration, we've determined that updating TimeZone would cause too much breaking changes because of the Vista Dynamic Time Zone support. APIs like "GetUtcOffset" and "IsDaylightSavingTime" works on a totally different logic.

Thanks,

Kathy

re: System.TimeZone2 Starter Guide [Kathy Kam]

Kent Boogaart — Wed, 04 Oct 2006 06:30:04 GMT

Great to see the new functionality. Awful to see the naming choice. Sure, it's in the guidelines but I'd be challenging those guidelines. I can't think of any other type that follows this convention so now would be a good time to challenge.

Please don't send .NET the way of Java: a plethora of confusing naming (guidelines or not) and deprecated crap all over the place. Push the CLR team for a better long-term solution if needs be.

Great job on that new functionality though.

My 2c,

Kent

re: System.TimeZone2 Starter Guide [Kathy Kam]

KathyKam — Wed, 04 Oct 2006 07:07:20 GMT

Not that this is a great example...

X509certificate2

http://msdn2.microsoft.com/en-us/library/system.security.cryptography.x509certificates.x509certificate2.aspx

Designing System.TimeZone2 - Part 1 (API naming and new class or not)

Kathy Kam — Wed, 04 Oct 2006 08:23:28 GMT

Didn't I say it two weeks ago that API naming is the most difficult thing? :) My BCL post on System.TimeZone2

re: System.TimeZone2 Starter Guide [Kathy Kam]

chronos — Wed, 04 Oct 2006 11:55:08 GMT

I have not looked at the documentation for TimeZone2 yet, so I do not know how much these overlap. If you are replacing TimeZone, then how about making both TimeZone and TimeZone2 derive from the same interface (ITimeZone). That way it will be easier to move current code to the new TimeZone2.

[Off topic]

I am still very unhappy about DateTime. I would like to write my own replacement. Would you please either...

1) Provide an IDateTime (and update methods to the new signature), or

2) Unseal DateTime

re: System.TimeZone2 Starter Guide [Kathy Kam]

Micael Baerens — Wed, 04 Oct 2006 16:06:22 GMT

I'm sorry but this is just horrible, and IMO the guidelines are flat out wrong on this one.

It totally defies the normal way of naming a variable - for what it does. The number appended has no meaning what so ever in regards to the class.

In my mind you have 2 choices:

1) Call it TimeZone and make it a breaking change. Yes, it will hurt some people in a one-time upgrade - but the alternative hurts people all of the time. Have the courage to realize that this really is just a breaking change, and implement it. It's not the first time breaking changes have been introduced in the framework.

2) If it really is so much different than the regular TimeZone, name it after it's purpose, say ConvertibleTimeZone. Yes, this probably requires some thought, but you must be able to do better than TimeZone2.

Appending a number is an ugly, ugly hack, and the author of that particular guideline should be flogged (Brad is that you?). I would hate seeing something like this in the framework:

DateTime3 dt3 = new DateTime3(new TimeZone4);

DateTime2 dt2 = dt3 - new DateTime2(new TimeZone3);

TimeZone2 - first impressions

@ Head — Wed, 04 Oct 2006 17:20:38 GMT

Kathy Kam asked for feedback on Timezone2, so tonight I decided to have a bit of a play and these are

re: System.TimeZone2 Starter Guide [Kathy Kam]

Thomas Krause — Wed, 04 Oct 2006 17:27:22 GMT

The complete quote from the Framework Design Guidelines is:

"Do use a numeric suffix to indicate a new version of an existing API if the existing name of the API is the only name that makes sense (i.e., it is an industry standard), and adding any meaningful suffix (or changing the name) is not an appropriate option."

So there is no requirement to add a numeric suffix if you can add a "meaningful" suffix or change the name.

re: System.TimeZone2 Starter Guide [Kathy Kam]

BigJimInDC — Wed, 04 Oct 2006 18:40:24 GMT

What about this?

http://www.twinsun.com/tz/tz-link.htm

Basing the internals off of the Windows registry makes sense, as most likely the software will be running on Windows. But TZ does so much more. Is the BCL team even aware of TZ and what it does? And if so, why not match the functionality? TimeZone's are a part of the BCL because people should be able to rely upon them with 100% certainty that they do everything they might need them to do. TimeZone didn't come close, and from what I've read so far, TimeZone2 still doesn't get the job done.

re: System.TimeZone2 Starter Guide [Kathy Kam]

KathyKam — Wed, 04 Oct 2006 21:37:46 GMT

Hey @ Head,

You posted some great feedback. I will respond to them in my blog next week. :)

Cheers,

Kathy

re: System.TimeZone2 Starter Guide [Kathy Kam]

RubenP — Thu, 05 Oct 2006 00:35:55 GMT

@BigJimInDC: I've asked a number of times about tz (not just Kathy), but each and every time MS has carefully sidestepped those questions.

re: System.TimeZone2 Starter Guide [Kathy Kam]

Jarle Nygård — Fri, 06 Oct 2006 15:04:19 GMT

I'd just like to add my 5 cents in the naming discussion; TimeZone2 is just bad naming!

Moving it into another namespace is a bit better, but not really, that's just hiding the problem...

The best way, as far as I can see, would be to add the changes to the existing TimeZone class.

Any breaking changes; fine! We'll deal with that, as we've dealt with similar issues in the past!

And yes, an Ex suffix is even worse that a number suffix... Imagine a versjon 8 of TimeZone in 2024;

TimeZoneExExExExExExExEx tz = ...

Not pretty! :)

But the feature set looks nice! I'll have to get my ol' test PC up and running again and have ago at it! :)

Cheers,

Jarle Nygård

re: System.TimeZone2 Starter Guide [Kathy Kam]

Ciarang — Fri, 06 Oct 2006 15:48:17 GMT

Good to see this functionality coming in, though I am more concerned, like many people, with the DateTime issues relating to timezones. I hope the design of this class has been done with that in mind.

System.TimeZone2 Naming ... and related design guidelines

Krzysztof Cwalina — Sat, 07 Oct 2006 03:37:14 GMT

There is an interesting discussion on the BCL blog about a new BCL type called TimeZone2. Just take a

System.TimeZone2 Naming ... and related design guidelines

Krzysztof Cwalina — Sat, 07 Oct 2006 03:43:29 GMT

There is an interesting discussion on the BCL blog about a new BCL type called TimeZone2. Just take a

re: System.TimeZone2 Starter Guide [Kathy Kam]

kcwalina — Sat, 07 Oct 2006 03:46:09 GMT

Hi, this thread is great. Lots of passion. Which can only make the Framework better. Thanks for getting involved!

I am responsible for the design guidelines, so I thought I would provide some explanation and a call to action!:-)

You can read it at http://blogs.msdn.com/kcwalina/archive/2006/10/06/TimeZone2Naming.aspx

TimeZones

Community Blogs — Sat, 07 Oct 2006 05:08:46 GMT

Right now, there is no easy way to convert a time from one arbitrary timezone to another arbitrary timezone

re: System.TimeZone2 Starter Guide [Kathy Kam]

Sean — Sat, 07 Oct 2006 11:10:23 GMT

Taking two steps forward without taking any back

re: System.TimeZone2 Starter Guide [Kathy Kam]

David Braverman — Sat, 07 Oct 2006 20:29:05 GMT

IMO, the class doesn't actually represent a timezone; it represents a rule that applies to a timezone. As an immediate example, if you get "Pacific Time (U.S. and Canada)" from the registry today, you'll have the rules that apply right now in Los Angeles. But these are not the rules that apply in L.A. starting next March, nor are they the rules that applied in L.A. before April 1986. In other words, either IsDaylightTime(2007, 3, 16) will return false (which is incorrect) or IsDaylightTime(2006, 11, 1) will return true (which is also incorrect).

I think you really need to take a look Arthur Olsen's work at NIH, since he's really the go-to person for timezones. See, e.g., ftp://ftp.elsie.nih.gov/Pub/ for the latest tzcode file, and read the theory document.

re: System.TimeZone2 Starter Guide [Kathy Kam]

Kathy Kam — Mon, 09 Oct 2006 08:59:44 GMT

Hi David,

Actually, in Vista, if you get "Pacific Time(U.S. and Canada)", the TimeZone2 object we fill has all the rules of the Pacific time zone, not just the current one. This is part of the "Dynamic Time Zone support", I have been talking aobut. Therefore IsDaylightTime(2007, 3, 16) will return true. IsDaylightTime(2006, 3, 16) will return false.

Thanks, Kathy

re: System.TimeZone2 Starter Guide [Kathy Kam]

Michael Teper — Mon, 09 Oct 2006 22:57:36 GMT

Please, since this is just a rehash of the registry, use the Index value for ID rather than Key name. It is much friendlier to data storage!

re: System.TimeZone2 Starter Guide [Kathy Kam]

KathyKam — Mon, 09 Oct 2006 23:57:35 GMT

HI Michael,

It is interesting you brought this up. I was just on a thread with the Windows team about the fact that Vista has deprecated this "index" value.

Thanks, Kathy

re: System.TimeZone2 Starter Guide [Kathy Kam]

eman — Tue, 10 Oct 2006 02:56:30 GMT

I prefer key names as they are more descriptive than an index value. However, you could have the best of both worlds by creating an enumeration that specifies all of the valid key names. How about an overload that takes such an enumeration?

re: System.TimeZone2 Starter Guide [Kathy Kam]

Josh Einstein — Tue, 10 Oct 2006 18:39:47 GMT

You say "Hi, this thread is great. Lots of passion. Which can only make the Framework better. Thanks for getting involved!

I am responsible for the design guidelines, so I thought I would provide some explanation and a call to action!:-)"

But you are not listening to the majority of customers that are telling you the guideline is flat out wrong. You don't need to look much further than MSHTML to see why this is wrong.

In all likelihood, TimeZone was probably very rarely used anyway because it was virtually useless. Obsolete it and move it to System.Globalization.

When there is no good name...

ASP.NET Team Blogs — Tue, 10 Oct 2006 19:08:35 GMT

I noticed a good debate going on the BCL blog (and now Krzysztof Cwalina’s blog) about the naming of

Should Humans Be Called Ape2?

Omer van Kloeten's .NET Zen — Tue, 10 Oct 2006 23:17:41 GMT

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

re: System.TimeZone2 Starter Guide [Kathy Kam]

David — Thu, 12 Oct 2006 16:34:00 GMT

First off, guidelines are only guidelines. In this case, not a single consumer of the API is at all happy with the name. You are developing a product and that product will not be well accepted by your consumers. Change the name simply because we want you to change it. Ignore the guidelines to make your customers happy.

re: System.TimeZone2 Starter Guide [Kathy Kam]

chronos — Fri, 13 Oct 2006 03:07:16 GMT

As a customer, I am unhappy with the design of the type. I wish Microsoft would either 1) unseal TimeZone / TimeZone2 and DateTime or 2) create an ITimeZone and IDateTime so that I can replace the types. The interface option is more difficult because existing signatures would have to be changed to take advantage of it. I would replace it either way, so I do not mind what it is called.

re: System.TimeZone2 Starter Guide [Kathy Kam]

Kevin Daly — Fri, 13 Oct 2006 07:36:49 GMT

Actually, I'm just happy that this functionality is going to be provided at last (you could call it "Julie" for all I care).

Is this going to be part of ... .NET 3.5? or will it be included in .NET 3.0 for Vista?

re: System.TimeZone2 Starter Guide [Kathy Kam]

Hugh — Fri, 13 Oct 2006 16:00:00 GMT

Great to see some movement on the Timezone class.

Unfortunately there is still no support for timezones that:

a) Change UTC offset from year to year

b) Change Daylight savings offset from year to year (e.g. the Australian timezones in April of 2006, and the American timezones next year will extend the daylight savings into November).

A previous Microsoft approach has been to create newly named timezones for when things change but this caused a litany of problems for users.

A timezone for e.g. "(GMT-08:00) Pacific Time (US & Canada); Tijuana" should represent the timezone of the user for 2006 and 2007 regardless of whether the daylight savings calculation is different from 2006 and 2007.

This would require storing a set of daylight saving calculations for each every time it changes, rather than a single fixed calculation as per the Windows registry, but it's the only way to get it right!

re: System.TimeZone2 Starter Guide [Kathy Kam]

Hugh — Fri, 13 Oct 2006 16:07:19 GMT

Aha!

I see now that Vista will have support for exactly what I was talking about in my previous post:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/dynamic_time_zone_information.asp

re: System.TimeZone2 Starter Guide [Kathy Kam]

KathyKam — Sun, 15 Oct 2006 09:05:31 GMT

Hi Kevin,

It will be part of .NET Framework 3.5

Thanks,Kathy

re: System.TimeZone2 Starter Guide [Kathy Kam]

KathyKam — Sun, 15 Oct 2006 09:06:59 GMT

Hi David,

We do have customers who likes the naming. Of course we will take all of your feedback into account.

Thanks, Kathy

re: System.TimeZone2 Starter Guide [Kathy Kam]

KathyKam — Sun, 15 Oct 2006 09:08:37 GMT

Hi Chronos,

We sealed the class because the internals are quite complicated. We did not want users to accidentally corrupt it. Regarding your feature request "ITimeZone" or "IDateTime", we will defintiely look into it in our next release.

Thank you, Kathy

re: System.TimeZone2 Starter Guide [Kathy Kam]

KathyKam — Sun, 15 Oct 2006 09:10:06 GMT

Hi Hugh,

Yes, the new TimeZone2 class will support everything the Vista Dynamic Time Zone API supports. So we will have support for

a) Change UTC offset from year to year

b) Change Daylight savings offset from year to year (e.g. the Australian timezones in April of 2006, and the American timezones next year will extend the daylight savings into November).

Thanks, Kathy

re: System.TimeZone2 Starter Guide [Kathy Kam]

chronos — Mon, 16 Oct 2006 03:22:48 GMT

Kathy wrote:

"We sealed the class because the internals are quite complicated. We did not want users to accidentally corrupt it."

I do not mean to be rude, but I truly find this reasoning flawed. Typically, types are sealed to 1) promote optimization, or 2) control by ensuring that there never can be a replacement (such as System.String). Option 1 is really an excuse when the problem is with the runtime. Hopefully inlining will be improved with future releases. The Java runtime has been making great progress in this area lately.

However, if you will consider an interface for a sealed type, then what does it matter how complicated the internals are? As a developer, it is my type to create (extend). Any type can be corrupted during development. Fixing bugs are part of a developers job. But by sealing it, I do not even have a chance to extend it. I am forced to use it as it is. That does not seem right to me.

re: System.TimeZone2 Starter Guide [Kathy Kam]

Alan McBee — Mon, 16 Oct 2006 04:29:27 GMT

Maybe I missed something in the discussion, but it seems like the main argument against making this a breaking change is that you intend to deploy this as a replacement, not as another SxS, thereby breaking released code. (http://blogs.msdn.com/kcwalina/archive/2006/10/06/TimeZone2Naming.aspx). If this was not the case, you'd more seriously consider making a breaking change by either replacing the original TimeZone class, or maybe moving it out of the System namespace, or ...?

In a nutshell, your deployment decisions are driving the design of your naming guidelines. Correct? Does that seem as backwards to you as it does to me?

I'd rather you postpone introducting the new TimeZone class (named "TimeZone" not "TimeZone2") into the next version number, so that it will be keep that name that for software developed for the next 15 years, rather than make us live with a name that you couldn't do because of the way you wanted to distribute the bits.

re: System.TimeZone2 Starter Guide [Kathy Kam]

TheMuuj — Mon, 16 Oct 2006 18:18:45 GMT

First and foremost I want to reiterate that I'm glad better timezone support is being added. We've all been asking for this for a long time. But I'd hate to see it messed up in this iteration and be forced to use a TimeZone3 to finally get it right (hey, third time's a charm).

I still don't see why this has to be in the System namespace. Worse yet, it's not even in mscorlib.dll or System.dll, which means that when I want to use it I have to try to remember what library it's in. I think the System namespace needs to be frozen very soon, with very few exceptions.

Consider putting it in a System.Core, System.Time or maybe System.Temporal namespace. Along with it you can add a time+timezone class/struct that's easily (maybe implicitly) convertible to a UTC DateTime.

It's a shame there's no way to simultaneously obsolete a class and create a new one with the same name. I can think of possible ways to add this kind of support to the runtime (similar to type-forwarding), but documentation could be a nightmare.

I also agree that the new TimeZone shouldn't be a sealed class. (I'm not going to say that DateTime should be unsealed because it's a value type). We should be able to create new timezones with pure managed code. The system time zones could be an internal sealed SystemTimeZone class that makes all the complicated calls to Vista's new APIs. Granted, sealing it probably makes serialization easier since you don't have to worry about custom timezones on the other end of the wire.

How does that work, anyway? What if you serialize a Vista time zone and send it to a Windows 2000 machine? Is the data from the registry actually serialized as well? Could we use Vista timezones on 2000 simply by remoting a Vista server? That seems both cool and silly at the same time! (I got an idea for a web service!!)

I'll admit the current System.TimeZone class is a complete mess. It's difficult to tell which methods should be overriden to do what, but I've had luck in creating timezones for everything from simple UTC offsets to historical timezones based on open-source timezone data.

re: System.TimeZone2 Starter Guide [Kathy Kam]

KathyKam — Wed, 18 Oct 2006 03:11:26 GMT

Hi Chronos,

My bad... what I meant to say was

"We made the class immutable because the internals are quite complicated. We did not want users to accidentally corrupt it. "

Which totally didn't answer your question. That's what I get for trying to reply blog comments at 2am on a Sunday! :P

Regarding why we sealed the class. That's more of a cost/benefit analysis on what we'd like to deliver in the Orcas time frame. I know that's not the best reason out there. Every feature (including unsealing a class) cost an amount of resources. There is an opportunity cost to every decision. We cut that "feature" because there are other features for the Orcas timeframe we have prioritized higher. In the next CTP, you'll get to see what other features the BCL team has come up with! Stay tuned!

Thanks, Kathy

re: System.TimeZone2 Starter Guide [Kathy Kam]

KathyKam — Wed, 18 Oct 2006 03:22:47 GMT

Hi Alan,

Actually, Krzsyztof's statement is a little misleading. He is correct that we'll never have a breaking change in a service pack.

"Changing TimeZone APIs in Orcas would amount to breaking applications in a service pack. This is a big no-no"

However, that doesn't mean we're adding a new type just because this is a service pack / in-place release. If it boils down to just that question. We would have waited a release and did a red-bits changed. You are correct, deployment strategy driving our framework design is bad news all around.

However, in this case, it was different. After some investigation, we decided that we would have added a new type even if we are allow to modify mscorelib.dll.

I discuss this indepth here: http://blogs.msdn.com/kathykam/archive/2006/10/03/Designing-System.TimeZone2-_2D00_-Part-1-_2800_API-naming-and-new-class-or-not_2900_-.aspx

Thanks, Kathy

re: System.TimeZone2 Starter Guide [Kathy Kam]

KathyKam — Wed, 18 Oct 2006 03:25:49 GMT

Hi TheMuuj,

We plan on posting something about serialization and other more advance samples on the new TimeZone2 class. Keep checking back~

Cheers, Kathy

re: System.TimeZone2 Starter Guide [Kathy Kam]

Angstrom — Tue, 31 Oct 2006 22:00:58 GMT

Let me first start by saying I applaud your efforts. The application that I'm currently working on is 1 million+ lines of .Net 1.1 code (moving to 2.0 this winter). I was dismayed when I saw how little support there was for TimeZone manipulation in 1.1

One of the parts of the application uses a time based concurrency model to collect data from multiple sources that may be in different time zones. To get around the timezone short coming we wrapped the already functional Win32 TIME_ZONE_INFORMATION and used a combination of UTC/Local time conversions with System.Time to pull it off.

My first reaction to the TimeZone2 addition was an explitive, but after seeing the direction layed out I'm glad to see that better judgement is prevailing. If this is followed in other cases similar to this I will be pleased. (and as far as the naming goes, myself, and hopefully most of the sane people would rather have a numeric suffix than a whole different name)

.Net Framework 3.5 - System.Core.dll

Mike Chaliy's Blog — Thu, 15 Feb 2007 17:42:01 GMT

Незабаром в нас буде нова версія .Net Framework 3.5, яка схоже, як і 3.0, буде спиратися на базовий .Net

And so it begins...

Johannes Hansen's Blog — Wed, 28 Feb 2007 07:57:21 GMT

"The .NET framework is awesome." That has been my position for a few years now and probably will be for

Exploring Windows Time Zones with System.TimeZoneInfo [Josh Free]

BCL Team Blog — Thu, 07 Jun 2007 23:42:17 GMT

The main feature of the System.TimeZoneInfo class (previously named System.TimeZone2 in CTPs prior to

New .NET 3.5 core stuff

Patrick Smacchia [MVP C#] — Wed, 08 Aug 2007 22:22:10 GMT

While installing VisualStudio 2008 Beta2 I was surprised that the NET framework 2.0 installation got

Time Zone Issues

Stephen Wright — Thu, 15 Nov 2007 11:37:43 GMT

Sounds like a book title, doesn't it? It's a horror story. Currently, I'm using a class library

.NET Framework 3.5 Now Available! [Justin Van Patten]

BCL Team Blog — Tue, 20 Nov 2007 03:39:59 GMT

.NET Framework 3.5 and Visual Studio 2008 have officially shipped! Soma has the announcement on his blog

Where has TimeZone2 class gone?

Righthand blogs — Thu, 06 Dec 2007 01:58:06 GMT

If you are following blogs about .net 3.5 you might have across this interesting post . It explains the

Where has TimeZone2 class gone?

MihaM — Thu, 07 Feb 2008 00:23:56 GMT

If you are following blogs about .net 3.5 you might have across this interesting post . It explains the

Where has TimeZone2 class gone?

Zunanji viri — Thu, 07 Feb 2008 00:53:39 GMT

If you are following blogs about .net 3.5 you might have across this interesting post . It explains the