TimeZoneInfo.AdjustmentRule Error Bug

  • Thread starter Thread starter Techno_Dex
  • Start date Start date
T

Techno_Dex

Correct Most of the Time but Not Always
http://msdn.microsoft.com/en-us/library/system.timezoneinfo.adjustmentrule.aspx

In looking at the sample code MS provided for the TimeZoneInfo class, there
appears to be a bug in the way that it's implemented. Daylight Saving Time
for 2006 and before followed the rule Starts the First Sunday of April and
Ends the Last Sunday of October. Well apparently there is some funny math
going on as well which doesn't appear to be documented. The US doesn't use
a Fixed Day for the DST switch, rather it uses a position day of week in a
month. The issue I'm having is apparent in the Year 2003 where
transitionStart.Week is returning a value of 1 instead of 2.

The C# sample code would indicate in the US that "Every [Sunday] of the
[First] Week of [April] at [2:00AM]" is when DST starts. In the case of the
Year 2003, The First Week of April on a Gregorian calendar does not contain
a Sunday (4/1 is on a Tuesday) but transitionStart indicates that does
because the transitionStart.Week value = 1 when it should equal 2. This
might make sense if the Calendar was Broadcast (i.e. First Day of the Week
is a Monday), but this would then break the "Every [Sunday] of the [Fifth]
Week of [November] at [2:00AM]" code for the transitionEnd which indicates
that the transitionEnd.Week value = 5. There is a flaw in the logic of this
Class. Where the funny math comes in would be if MS is checking that the
Month has changed to something different than the value in the
transitionStart and transitionEnd and either Add 7 Days or Subtract 7 Days
to return the correct value as need. Am I missing something here????
 
It would appear the MS updated their documentation in Oct of 2008 but it
hasn't been floated up enough on the Web to counteract existing
documentation that has previously been published.

The way the code is now to be Read is:
Begins at [2:00AM] on the [First] [Sunday] of [April]
Ends at [2:00AM] on the [Fourth] [Sunday] of [October]
Ends at [2:00AM] on the [Last] [Sunday] of [October]

This means the transition.Week value takes on a different mean for the value
of 5. Instead of being Fifth Week it's now Last Week which indicates that
special processing needs to be done in the case of Week=5. Couple this with
the change in language which indicates that the .Week property is now
counting the number of DayOfWeeks in a month instead of number of Weeks in a
month and then find the DayOfWeek. I'm still reviewing test cases to ensure
this functionality works as well.

In other words: This is bad documentation
http://msdn.microsoft.com/en-us/library/system.timezoneinfo.adjustmentrule.aspx

This is good documentation:
http://msdn.microsoft.com/en-us/library/system.timezoneinfo.transitiontime.week.aspx


Techno_Dex said:
Correct Most of the Time but Not Always
http://msdn.microsoft.com/en-us/library/system.timezoneinfo.adjustmentrule.aspx

In looking at the sample code MS provided for the TimeZoneInfo class,
there appears to be a bug in the way that it's implemented. Daylight
Saving Time for 2006 and before followed the rule Starts the First Sunday
of April and Ends the Last Sunday of October. Well apparently there is
some funny math going on as well which doesn't appear to be documented.
The US doesn't use a Fixed Day for the DST switch, rather it uses a
position day of week in a month. The issue I'm having is apparent in the
Year 2003 where transitionStart.Week is returning a value of 1 instead of
2.

The C# sample code would indicate in the US that "Every [Sunday] of the
[First] Week of [April] at [2:00AM]" is when DST starts. In the case of
the Year 2003, The First Week of April on a Gregorian calendar does not
contain a Sunday (4/1 is on a Tuesday) but transitionStart indicates that
does because the transitionStart.Week value = 1 when it should equal 2.
This might make sense if the Calendar was Broadcast (i.e. First Day of the
Week is a Monday), but this would then break the "Every [Sunday] of the
[Fifth] Week of [November] at [2:00AM]" code for the transitionEnd which
indicates that the transitionEnd.Week value = 5. There is a flaw in the
logic of this Class. Where the funny math comes in would be if MS is
checking that the Month has changed to something different than the value
in the transitionStart and transitionEnd and either Add 7 Days or Subtract
7 Days to return the correct value as need. Am I missing something
here????
Click to expand...
 
Back
Top