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.