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.
Let's take a look at "IsDaylightSavingTime".
public bool IsDaylightSavingTime (
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.
- 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 (
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?