QTimeZone is no longer dependent on feature timezone, only its
backends are. We can also pass it as test data, rather than only its
name. So replace the zoneName column with a plain zone column, make
the UTC row for the epoch use QTimeZone::UTC instead of "UTC" and make
only the remaining rows depend on the feature, and then only for their
test using the backend zone.
The test itself was doing some convoluted twists to check local time
handled the relevant dates and times as expected. Where local time is
the zone the test relates to, this can just as well be handled by
adding a separate row for it - which we can even do without feature
timezone.
Otherwise, testing an expectation that local time *doesn't* have
anything odd going on for the selected days was somewhat unreliable,
as other zones that coincide with the tested zone for that particular
date would fail. So just drop that unreliable side of the local-time
testing.
Change-Id: Id58b2d4cf7649567f1831154a605f31139e987d3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
e3efcc8044