diff options
author | Marc Blank <mblank@google.com> | 2011-11-17 11:29:13 -0800 |
---|---|---|
committer | Marc Blank <mblank@google.com> | 2011-11-17 11:37:41 -0800 |
commit | 2c7d44b182654120a98921cbc864be2d135c8fda (patch) | |
tree | 8ee1b40070f5da8a4216f96ac154ed85dd1cbac7 /tests/src | |
parent | 3eda7645da3d695d6c487f138a0167c221e875a5 (diff) | |
download | android_packages_apps_Exchange-2c7d44b182654120a98921cbc864be2d135c8fda.tar.gz android_packages_apps_Exchange-2c7d44b182654120a98921cbc864be2d135c8fda.tar.bz2 android_packages_apps_Exchange-2c7d44b182654120a98921cbc864be2d135c8fda.zip |
Attempt to better handle screwy MSFT time zone information
* Exchange appears to send time zond data that doesn't really match
any time zone in our database; in these cases, we have been
returning a random one with the same bias (base offset w/o DST)
* In this CL, we try to do better by giving the time zone information
a bit more slack when the regular determination fails (we allow
the hour of change to be up to 4 hours different from expected,
rather than one minute). This is certainly better, though I do
not have an explanation from MSFT about the reason for the
erroneous data.
* Updated unit tests to confirm that we don't break any existing
code and do, in fact, handle the case reported below as a P1/S1
bug.
Bug: 5605219
Change-Id: I8c17a687404204aff4feb1c3009adde279110cab
Diffstat (limited to 'tests/src')
-rw-r--r-- | tests/src/com/android/exchange/utility/CalendarUtilitiesTests.java | 18 |
1 files changed, 18 insertions, 0 deletions
diff --git a/tests/src/com/android/exchange/utility/CalendarUtilitiesTests.java b/tests/src/com/android/exchange/utility/CalendarUtilitiesTests.java index b883b5a2..0ecdb8fd 100644 --- a/tests/src/com/android/exchange/utility/CalendarUtilitiesTests.java +++ b/tests/src/com/android/exchange/utility/CalendarUtilitiesTests.java @@ -103,6 +103,13 @@ public class CalendarUtilitiesTests extends SyncAdapterTestCase<CalendarSyncAdap "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgAYQB3AGEAaQBpAGEAbgAgAEQAYQB5AGwAaQBnAGgAdAAgAFQA" + "aQBtAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=="; + // This is time zone sent by Exchange 2007, apparently; the start time of DST for the eastern + // time zone (EST) is off by two hours, which we should correct in our new "lenient" code + private static final String LENIENT_EASTERN_TIME = + "LAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" + + "AAAAAAAAAAsAAAABAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" + + "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAACAAAAAAAAAAAAxP///w=="; + private static final String ORGANIZER = "organizer@server.com"; private static final String ATTENDEE = "attendee@server.com"; @@ -132,6 +139,17 @@ public class CalendarUtilitiesTests extends SyncAdapterTestCase<CalendarSyncAdap assertEquals("Asia/Calcutta", tz.getID()); tz = CalendarUtilities.tziStringToTimeZone(AUSTRALIA_ACT_TIME); assertEquals("Australia/ACT", tz.getID()); + + // Test peculiar MS sent EST data with and without lenient precision; send standard + // precision + 1 (i.e. 1ms) to make sure the code doesn't automatically flip to lenient + // when the tz isn't found + tz = CalendarUtilities.tziStringToTimeZoneImpl(LENIENT_EASTERN_TIME, + CalendarUtilities.STANDARD_DST_PRECISION+1); + assertEquals("America/Atikokan", tz.getID()); + tz = CalendarUtilities.tziStringToTimeZoneImpl(LENIENT_EASTERN_TIME, + CalendarUtilities.LENIENT_DST_PRECISION); + assertEquals("America/Detroit", tz.getID()); + tz = CalendarUtilities.tziStringToTimeZone(GMT_UNKNOWN_DAYLIGHT_TIME); int bias = tz.getOffset(System.currentTimeMillis()); assertEquals(0, bias); |