This is part two of a series of posts describing a potential new API for dealing with countries, country subdivisions and timezones in KI18n, following the previous one on ISO codes, covering how we can query the timezone of a country or a country subdivision.

Features

This time we are looking at merely two methods:

  • KCountry::timeZoneIds() - returning all timezones applicable in a country.
  • KCountrySubdivision::timeZoneIds() - returning all timeonzes applicable in a country subdivision.

Those are interesting when needing to determine the timezone at a given address for example. And while not possible everywhere, these actually have a unique result in the majority of countries, which is when this is most useful.

Data Sources

While this ultimately is just a small table with a few hundred entries, it’s actually rather complicated to get to.

The official IANA zonetab has at least some data on countries, but for the country subdivisions we need more. The most detailed data in this regard is the IANA timezone boundaries dataset, which contains high resolution geographic areas for each timezone, generated from OSM.

Inspired by that I built a similar dataset for countries and country subdivisions boundaries some time ago. What we are looking for now is the intersection of those two.

Not something one would want to implement manually, but fortunately QGIS provides the right tools for this already. We use that in form of a Python script that can run inside QGIS, download and unpack the needed data files, preprocess them for our use, compute the data we need from then and then generate C++ code from that.

Historical Correctness

For practical use, the best case result is a unique timezone for a country (for the ~200 countries that only have a single timezone of course). Implemented as outlined above we’ll get multiple results for a number of countries that only seem to have a single timezone though, such as Argentina or Germany.

The reason for that is that there are more than 400 timezones defined in the IANA database, many of which are in sync today, but differed at some point in the past. Argentina for example used to be split in 13 timezones until 1993, and Germany has a small enclave in Switzerland that changed to DST together with Switzerland rather than Germany in 1980.

So there is a tradeoff to be made between accurate results for past times, or for more useful (unique) result today and the near future. The Python script doing the processing therefore can be configured to filter out selected purely historic zones. This helps with cases like Argentina or Germany, but then there’s this madness which we can’t do much about.

Outlook

Feedback for this is very welcome, on the implementation but also regarding use-cases and requirements you have in your application. Check the corresponding Phabricator task and the Gitlab branch for this, or find me in the #kde-devel channel on Matrix, the weekly KF6 meetings or the kde-frameworks-devel mailing list.

The next part is probably going to be about querying country, country subdivision and timezone information based on geographic coordinates.