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: 5605219
Change-Id: I8c17a687404204aff4feb1c3009adde279110cab
2 files changed