TimeZoneInfo.Local vs TimeZoneInfo.FindSystemTimeZoneById

Question

I\'ve been working with the DateTime and TimeZoneInfo classes and I ran into an interesting result with the following code:

var dstStar         


        

Answer 1

The difference in behavior when using the non-Local TimeZoneInfo is defined in the MSDN documentation.

The reason the first result is False is because the DateTime object you have created is technically ambiguous. There is no 2:00 am on March 10 2013 in the EST local time zone.

The doc states that the IsDaylightSavingTime() method is "affected by the relationship between the time zone represented by the TimeZoneInfo object and the Kind property of the dateTime parameter". The table in the Remarks section provides a description of each of the possible combinations.

When specifying a time zone by explicitly calling FindSystemTimeZoneById, the "Local Kind" DateTime argument is first converted from Local to the specified time zone. During this step, the ambiguous time is resolved into a legitimate value.

Try adding this to your test:

var dstStart = new DateTime(2013, 3, 10, 2, 0, 0, DateTimeKind.Local);

dstStart = dstStart.ToUniversalTime();
dstStart = TimeZoneInfo.ConvertTime(dstStart, TimeZoneInfo.Utc, myTimeZone);

The final value of dstStart becomes '3/10/2013 3:00:00 AM' (assuming your machine is still in EST). The same kind of conversion is happening within IsDaylightSavingTime() on the local kind parameter, which illustrates why it returns True.

The real surprise here is that the IsDaylightSavingTime() method doesn't raise an ArgumentException in either case. The documentation says that it will throw an exception when given an invalid DateTime parameter whose kind is DateTimeKind.Local, but clearly this does not happen.

Edit:

After looking through the source code and comments for the TimeZoneInfo class, I've come to the conclusion that the IsDaylightSavingTime() method is not meant to throw exceptions. This is a mistake in the documentation.

Answer 2

I did a little bit of reflecting and I believe the inconsistency stems from how System.TimeZoneInfo+CachedData.GetCorrespondingKind(TimeZoneInfo timeZone) returns DateTimeKind.Local only in the case where timeZone == this.m_localTimeZone (ie, when the argument was the same instance as the TimeZoneInfo.Local property is based on).

In the case where you pass this other TimeZoneInfo instance you got from TimeZoneInfo.FindSystemTimeZoneById I expect that it returns DateTimeKind.Unspecified.

This will (probably among other things) affect System.TimeZoneInfo.IsDaylightSavingTime(DateTime dateTime) where, in the case where dateTime.Kind is local, it does a conversion between essentially TimeZoneInfo.Local and your TimeZoneInfo instance and bases the conversion on what GetCorrespondingKind says for the source and target timezones (the conversion returns the original datetime in the case where source and target are both local).