Fix replacement time zone ID generation logic
This change corrects the logic used to determine the replacement time
zone ID in tzlookup.xml and tzids.prototxt, i.e. for a zone which has
ceased to become distinct from other zones, this alters the logic that
determines the ID of the zone we say replaces it.
The old logic would follow the zone tree to the root. In some cases that
resulted in an incorrect replacement, for example: when there are two
zones with the same offset, but one that has DST and one that doesn't,
the zone tree will often merge them near the root if the period at the
root (the furthest future period materialized) happens to match. An
example might be America/Phoenix and America/Denver, where Denver
observes DST and Phoenix doesn't, but they both use Mountain Time so
are the same for 6 months of the year. If the generation of time zone
periods happens to stop in that six month period then the algorithm
thinks they "merge" because there's nothing later in time to contradict
it.
The new logic just looks ahead by one period. This means that the user
of the file may have a few "hops" to follow, but this also means that
the hops can stop being followed after an arbitrary time (by observing
notafter=), which is also useful if there are replacements in the future
that the user is not interested in.
The output data has changed because of the "hops" effect, but only some
zones in Canada and one in USA (America/Boise) have actually changed the
final replacement ID if the hops are all followed.
Bug: 171796385
Test: Inspection of output
Test: cd input_tools/android/tzlookup_generator; atest --host .
Change-Id: Iaea05ba7c54c9d2f644c8485f1d9fd79d472cab2
12 files changed