Designing System.TimeZone2 - Part 2 (Dynamic Time Zone support)

There are some great discussion on the differences between System.TimeZone and System.TimeZone2 and what exactly is Vista Dynamic Time Zone in my previous post. So I thought I'll spend Part 2 talking about it.

So what exactly is the difference? I have mentioned again and again that the difference is in "Vista Dynamic Time Zone support". But another major difference is that, in System.TimeZone the only time zone you can use was current time zone. That's it. TimeZone2 is way more flexible than that. Users can create their own time zone using the CreateTimeZone API or use the OS provided time zone. (I really need to blog about the CreateTimeZone API... that's on my to-do list)

"So what exactly is this "Vista Dynamic Time Zone support"?"

The word "dynamic" itself is a little misleading. It is not "dynamic". It is more "historic" or "futuristic". "Dynamic time zone data" is just the new registry structure that Vista has introduced so that an application can query a time zone's historic (and future) data. It is dynamic in the sense that as you move forward it time, the OS will update your current time zone information based on the data.

"So does TimeZone2 do different things on different OS?"

Short Answer: No it does not.

Long Explaination:

Let's take a look at "IsDaylightSavingTime".

For System.TimeZone2:
public bool IsDaylightSavingTime (
   DateTime time
)

On Vista, if you call FindSystemTimeZoneById, TimeZone2 will be populated with historic and future time zone data (aka dynamic time zone data). On Win XP, if the OS has not been updated with this new data (we are hoping that Windows will backport dynamic time zone data to XP btw...), TimeZone2 will be populated with the current time zone data the OS provides. TimeZone2 doesn't have different logic. The difference here is the data that was provided by the OS. The difference is in FindSystemTimeZoneById(). The call "IsDaylightSavingTime()" does the same thing in both OS. 

Two TimeZone2 object with the same data will return the same thing across all the instance methods. You can populate a TimeZone2 object with historical data in WinXP and it will work like it does in Vista. Similarly you can also populate a TimeZone2 object without historical data in Vista and it will work like it does in XP. It all works the same.

The only difference the different OS brings is in the static methods that queries data from the OS. If the OS have different data, the static methods will return different results. This is no different to if you call "GetOSHelloString()" and one OS returns strHello = "Hello World", and another reutrns strHello = "Hello". Would you consider strHello.Length returnng different results and "doing different things on different OS"?

The APIs that calls the OS to get the data all have the word "SystemTimeZone" in it.

- GetSystemTimeZone()
- FindSystemTimeZoneById(string id)
- ConvertBySystemTimeZoneId(string id)

So the "SystemTimeZone" APIs are really helpers for you to get to the OS time zone data. TimeZone2 can operate on other data. (Again, I really need to post a blog about the CreateTimeZone APIs... )

For developers who wants to use OS data but is worried about different OS having different data, we do recomend them serializing the TimeZone data when doing cross application communication.

Now let's look at System.TimeZone, for the same API. It behaves completely differently.
public static bool IsDaylightSavingTime (
   DateTime time,
   DaylightTime daylightTimes
)

First of all, it is a static method. Secondly, it takes a DaylightTime to calculate whether it is in daylight saving time. It has no understanding of the OS time zone data.

This is why just augmenting or changing System.TimeZone will be a huge breaking change for our exisiting customers. Basically, we'll gut System.TimeZone and replace it with what we call "System.TimeZone2". When we realize that's what we'll do. We decided that we are basically creating a new type. Thus, the birth of System.TimeZone2.

Does this make sense? Do you agree? Disagree?

Comments

• Anonymous
  October 05, 2006
  As others have questioned, I also would like this addressed.Why are you using Vista Dynamic Time Zone? Quote: "we are hoping that Windows will backport dynamic time zone data to XP"TZ should be a viable solution for multiple platforms, including XP: http://www.twinsun.com/tz/tz-link.htmHave you investigated obtaining the time zone data from TZ? Why was it rejected? It seems that it could provide so much more.

• Anonymous
  October 05, 2006
  How can anyone name a class TimeZone2??Sorry but this is probably the most stupid name you could come up with.If it is based on "Vista Dynamic Time Zone support" why not just name it DynamicTimeZone or TimeZoneDynamic?Just about everything would be better than TimeZone2!!And don't even think naming it TimeZoneEx, because THAT would be the exception!

• Anonymous
  October 06, 2006
  Well, if I understand the '"dynamic" itself is a little misleading. [...] It is more "historic" or "futuristic".' right, then the DST calculation is based on the year in the DateTime passed into IsDaylightSavingTime and not based on the current years DST settings or supplied DatelightTime argument? E.g. if the DST calculation is different for each year for the systems time zone, TimeZone2.IsDaylightSavingTime will return the proper value based on the year and not on the current year like it does now? At least that is what seems to happen based on a quick look at Alaskan Standard Time in the registry. P.S.: I hate DST with a passion, even the ones with the simple rules :)

• Anonymous
  October 06, 2006
  Hi Foxfire, Please read my Part 1 in the "Designing TimeZone2". I talk about why it was named TimeZone2. If you have more question. Let me know.. Thanks, Kathy

• Anonymous
  October 06, 2006
  Hi Bjorn, You are correct, IsDaylightsavingTime will be based on the dateTime passed in NOT the current daylight saving rule the app is being run. Thanks, Kathy

• Anonymous
  October 07, 2006
  Any chance of having a BCL class that combines DateTime and TimeZone2? I can see a lot of people needing to treat pairs of DateTime and TImeZone2 objects as an atomic object, and if the BCL doesn't support this then we are going to see a lot of duplication.

• Anonymous
  October 09, 2006
  Hi Jonanthan, Thanks for the feedback. We will definitely look into that. Thanks, Kathy

• Anonymous
  October 09, 2006
  I would really welcome a new DateTime class. Hopefully it can be done right this time by being based only on UTC. I would like to create my own replacement, but Microsoft has seal DateTime and not provided an IDateTime interface either...

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

• Anonymous
  November 08, 2006
  Hello, Thank you for your efforts in updating this class.  I think naming is important, but personally, I'm too busy to worry about it, let alone get upset about it. My question is, as a person who is currently trying to localize time for a client using the current framework, what are our options for converting times back and forth using a timezone today?  Not being on a dedicated server, I don't think I have permissions to read the registry either.  I just have a UTC time in the db and a string such as PT.  Should I just create my own list of offsets?  Is there a c# resource for getting DST rules? Thanks for any info you offer, John

• Anonymous
  November 08, 2006
  Having built my own TimeZone class for a very large international law firm (because the System.TimeZone class is ridiculously short-sighted), I have done a lot of research about time zones and daylight saving time   around the world and am very interested to see how this plays out. I've been reading a lot of comments in several blogs about the TimeZone2 proposal.  This is my take on the whole thing.

1. TimeZone2 should not be based on the Vista "dynamic/historic timezone API", it should contain all the logic/data to compute this independent of the OS.  This is so much easier for the developer, less things to think about and consider.    
2. TimeZone is a broken, almost useless class.  The ideal recourse is to replace it - it is already broken.  That said, if you are adamant about not replacing it, the new name should describe a class which clearly indicates that it is a replacement and therefore I am ok with the TimeZone2 name.
3. Define interfaces so we have more flexibility... such as IDateTime and ITimeZone.
4. May I suggest an instantiation of a TimeZone2 object have the methods: ToLocalTime(DateTime utcDateTime) ToUniversalTime(DateTime localDateTime) but still maintain the "ConvertTime" static method. I named my static method "ToOtherTimeZone", but I like "ConvertTime" as well. Also, I don't like this: TimeZone2.FindSystemTimeZoneById(“Hawaiian Standard Time”); I would like all the time zones be listed, like the Color class lists many colors.  Easier discoverability, strongly typed (no misspelling bugs), less frustration and time wasted looking things up on msdn or wherever. Last but not least.  I am very happy you guys are working on this TimeZone thing.  The framework certainly needs it! Cheers, Jules

• Anonymous
  November 24, 2006
  I agree but, is IsDaylightSavingTime just a sample among a lot of behavior changes? Because, otherwise I think another path to take is to add a new methods, say IsDaylightSavingTime2 ;)... I swear, I am not in a "we are all API designers" mindset, but I am curious.

• Anonymous
  December 07, 2006
  Hi Jules, In response to your comment:

1. Whether the framework should own the time zone data was a HUGE decision for us. Owning the data comes with maintaining the data and updating the data when it changes. Unfortunately, after evaluating costs, size of the framework and balancing the needs of our customers to have accurate data. We find that depending on OS data is the best course of action. That was a tough decision.
2.  Thank you for your suggestion. We will definitely look into it. One step at a time.. :) Provide what everyone nees that System.TimeZone doesn't provide, and next is to allow people to extend it.
3. We do have ToUniversalTime..etc. I haven't posted the full API. Ennumeration of the time zone has been asked for again and again. Not giving it is a result of the tough decision in #1 I mentioned above. Because the OS owns the data, and they don't promise any ennumeration. We cannot provide it. :(

• Anonymous
  February 12, 2007
  chronos stated "TZ should be a viable solution for multiple platforms, including XP: http://www.twinsun.com/tz/tz-link.htm Have you investigated obtaining the time zone data from TZ? Why was it rejected? It seems that it could provide so much more. " I'd love to hear a response to this since I think that operating off the same data source would make this timezone support more robust and enterprise friendly.  It's a lot easier to sell a solution to a client saying "it's been used in Oracle, Linux, Java, and now in .Net".  There's even existing code on how to do this - http://www.babiej.demon.nl/Tz4Net/main.htm .  I beg you to give us TZ support.

• Anonymous
  April 04, 2007
  Based on the support for multiple timezone rules in Vista I was assuming that my existing .NET 1.1 code that uses the DateTime class with historical values would automatically pick up the change.  After putting together a simple test, it appears that is not the case.  Are there plans to either correct this in DateTime or define new classes that handle this correctly moving forward?

• Anonymous
  April 04, 2007
  Hi Andrew, We are definitely looking ino fixing it in the future. Thanks, Kathy