timezone: Fix resolving of proper ISO3166 code from tz data #44
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mlehtima
approved these changes
Jun 7, 2023
pvuorela
approved these changes
Jun 7, 2023
[timezone] Fix resolving of proper ISO3166 code from tz data. Fixes JB#60842 It is possible that the region set as localtime region may have matches in either of the zone map files. And in some cases there may be ISO3166 codes in the deprecated files that are not supported by the backends such as gsupplicant to set the regulatory domain. Ålands/Mariehamn is an example of this since as a region it only exists in zone.tab and provides ISO3166 code AX which cannot be supported as regulatory domain. But zone1970.tab contains the ISO3166 as a sub-region code for Finland (FI) that should be set. Furthermore, the timezone files for sub-regions, like with Ålands in Finland and Pacific/Midway as UM -> AS, are identical copies and cannot be compared solely by checking the mmap()'d entries. The path needs to be taken into account or wrong region might be generated as a search parameter for getting the ISO3166 code. Otherwise the results in some cases might be ambiguous and the localtime set would yield another region as a search parameter for the ISO3661 code. Therefore, these changes add the real path utilized from the Localtime path set in ConnMan settings to be used along the comparison of timezone files. And the resolving of the ISO3661 code supports now more laborous search if the code is not found using the region as a search parameter. In such case the ISO3661 code is attempted to be searched from the deprecated tz map and when found this code is used to search the zone1970.tab again for a match in any of the defined ISO3166 string lists. As a result the ISO3166 code of the main region is set that should be supported by the varying backends to set the WiFi regulatory domain.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It is possible that the region set as localtime region may have matches in either of the zone map files. And in some cases there may be ISO3166 codes in the deprecated files that are not supported by the backends such as gsupplicant to set the regulatory domain. Ålands/Mariehamn is an example of this since as a region it only exists in zone.tab and provides ISO3166 code AX which cannot be supported as regulatory domain. But zone1970.tab contains the ISO3166 as a sub-region code for Finland (FI) that should be set.
Furthermore, the timezone files for sub-regions, like with Ålands in Finland and Pacific/Midway for US, are identical copies and cannot be compared solely by checking the mmap()'d entries. The path needs to be taken into account or wrong region might be generated as a search parameter for getting the ISO3166 code. Otherwise the results in some cases might be ambiguous and the localtime set would yield another region as a search parameter for the ISO3661 code.
Therefore, these changes add the real path utilized from the Localtime path set in ConnMan settings to be used along the comparison of timezone files. And the resolving of the ISO3661 code supports now more laborous search if the code is not found using the region as a search parameter. In such case the ISO3661 code is attempted to be searched from the deprecated tz map and when found this code is used to search the zone1970.tab again for a match in any of the defined ISO3166 string lists. As a result the ISO3166 code of the main region is set that should be supported by the varying backends to set the WiFi regulatory domain.