BillArmstrong
commented
6 years ago - Some time zones are created with missing TimeZonePeriod objects, resulting in an invalid TimeZoneDefinition structure that is rejected by the EWS service.
- The TimeZoneDefinition constructor handles time zones with undefined years BEFORE the collection of AdjustmentRules and AFTER the collection of AdjustmentRules, but it does not handle gaps IN BETWEEN AdjustmentRules. For example, say you have an adjustment rule from 2009 to 2010 and the next adjustment rule is from 2012-1016. In between 2010 and 2012 is the year 2011. This missing year indicates that there was no DST period during 2011. There needs to be a TimeZoneTransition for 2011 to indicate that there is no DST for that year.
- Some time zones have years where the standard period BIAS is different than the base BIAS defined in the TimeZoneInfo object. This is indicated by an AdjustmentRule that has a non-zero BaseUtcOffsetDelta property. Currently the EWS library does not take this value into account. By not taking this value into account, the created TimeZoneDefinition will have periods where the defined BIAS for the period is incorrect. NOTE that this is an internal property that can only be accessed through reflection.This issue only affects historical years. The current year is not affected (since the TimeZoneInfo object's bias is based on the current year), and at the time of this bug fix there are no time zones that have this problem for future years.
- The value written to the DateTime element on the AbsoluteDateTransition element is converted to UTC. The DateTime is primarily used to specify the start year for the transition. Converting the date to UTC may change the start year (depending on the time zone) that is written to XML. The date that is written to this element should not be converted to UTC.
- There is one time zone (Sao Tome Standard Time) that has a year with a DST period that lasts one hour. This time zone is rejected as an invalid time zone by EWS. The library was updated to treat years with DST periods lasting less than a day the same as years with no DST at all. This allows the time zone to be received by Exchange with no errors.
- Added a unit test project to unit test the conversion of TimeZoneInfo objects to TimeZoneDefinition objects.
msftclas