Home Dashboard Directory Help

TimeZoneInfo is incorrectly applying DST rules for zones in the southern hemisphere by mj1856


 as Fixed Help for as Fixed

Sign in
to vote
Type: Bug
ID: 800191
Opened: 9/10/2013 3:58:32 PM
Access Restriction: Public
User(s) can reproduce this bug


Time zones that are in the southern hemisphere and follow daylight saving time rules usually start their "summer time" towards the end of one year and end it at the beginning of the next. This is inverted from the rules followed in the northern hemisphere.

The Dynamic DST time zone data in the Windows Registry appears to be correct, but the TimeZoneInfo class is misinterpreting this by assuming that the start and end of DST are both in the same calendar year. This can be found in the private static method TimeZoneInfo.GetIsDaylightSavingsFromUtc.

This (among other issues) makes the TimeZoneInfo conversions unreliable for many time zones, such as those in Australia that follow daylight saving time.

More details here: http://stackoverflow.com/a/18649324/634824
and here: http://stackoverflow.com/a/18727400/634824

Actually, digging further, it may be slightly more subtle than what I described. I do see the check for the southern hemisphere in the CheckIsDst method. But it still isn't working with the example case I provided. It might have more to do with the fact that the Year parameter doesn't match the year of the rule, or in how the isAmbiguous method is being set.
Sign in to post a comment.
Posted by Tarek [MSFT] on 4/15/2014 at 9:11 AM
Thanks for reporting this issue. we'll look at fixing that in the future releases
Posted by Microsoft on 9/10/2013 at 11:16 PM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Microsoft on 9/10/2013 at 4:52 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.