Timezones known by Agama but not known by zone.tab

zones.md

The file zone.tab allow us to map timezones to a representative country. Basically, the country in which the city mentioned in the name of the timezone is located.

Good news - that mapping actually works for 434 of the timezones Agama offers.

Not so good, there are 39 missmatches. So there are timezones for which we cannot inferre the country.

Let's group them

A. No country, indeed

These 2 cases are actually not a mistake. They correspond to timezones that are not associated to any country:

• Antarctica/South_Pole
• UTC

B. Duplicated

These 9 cases correspond to timezones that are somehow duplicated in Agama. The timezone itself does not appear at zones.tab so we cannot infer the country. But Agama also offers another "equivalent" timezone that is present at zones.tab (ie. we can know the country).

• America/Buenos_Aires -> America/Argentina/Buenos_Aires
• America/Catamarca -> America/Argentina/Catamarca
• America/Cordoba -> America/Argentina/Cordoba
• America/Indianapolis -> America/Indiana/Indianapolis
• America/Jujuy -> America/Argentina/Jujuy
• America/Louisville -> America/Kentucky/Louisville
• America/Mendoza -> America/Argentina/Mendoza
• Asia/Istanbul -> Europe/Istanbul
• Europe/Nicosia -> Asia/Nicosia

B2. Not exactly a duplicate

There is 1 case that is similar to the previous ones, but in which the mapping between the timezone and its "duplicate" is not so clear.

• US/Alaska -> Somehow corresponds to America/Anchorage

C. Different name

In another 2 cases, the timezone is at zones.tab, but with a different name.

• Asia/Rangoon -> At zones.tab is listed as Asia/Yangon
• Europe/Kiev -> At zones.tab is listed as Europe/Kyiv

D. The country is unknown to Agama

There is 1 case for which we know the country code... but Agama doesn't know what that country code means because is not in the list of territories Agama gets from langtable.

• Atlantic/South_Georgia -> zones.tab points to country GS

E. Simply missing

In 19 cases, I don't know why the timezones are not known to zone.tab.

• America/Godthab
• America/Montreal
• America/Nipigon
• America/Pangnirtung
• America/Rainy_River
• America/Santa_Isabel
• America/Shiprock
• America/Thunder_Bay
• America/Yellowknife
• Asia/Chongqing
• Asia/Harbin
• Asia/Kashgar
• Australia/Currie
• Europe/Uzhgorod
• Europe/Zaporozhye
• Indian/Kerguelen
• Pacific/Enderbury
• Pacific/Johnston
• US/Arizona

IMHO, for the time being:

• I would have a hardcoded list with conversions from some Agama timezones to zone.tab timezones: this covers B, B2 and C.
• I would keep timezones in which its country cannot be inferred: this covers A, D and E.

I would say that keeping timezones without country is better than removing the timezone. In D-Bus, each time zone has a list with the translated parts. That parts could have a country or not.

I agree there is nothing wrong in having timezones without a country (as said, this is simply the right thing for South Pole and UTC).

But the fact a timezone is not at zones.tab (apart from the two mentioned justified absents) may be considered a warning about it.

Do we really need the 10 duplicated ones like twice Buenos Aires or twice Istambul?

Are the other 19 (case E) really trustworthy?

As said in the mail thread (but let's keep the whole conversation here), I would go for a different solution:

• Obviously in the case A there is nothing to fix.
• For C, I would add a couple of exceptions to the code, making the name conversion.
• I wouldn't know how to handle the case D. Keep the timezone without the country? Drop that timezone? Open a PR to langtable to add GS (South Georgia and the South Sandwich Islands)?
• For all other cases, I would first go for the drastic approach and would remove the timezones from Agama. We offer ~400 timezones, sure the users can find something that is fully equivalent.

Sorry, I did not explain it well. I did not propose to have duplicated timezones but something like the following algorithm:

a) Try to convert a timezone to another timezone (using a hardcoded list).
b) Discard a timezone if we already have processed that timezone.
c) Find country in zone.tab for the timezone.
d) Add translated country if the country is found in langtable.

With this we could limit to find/add countries without deciding ourselves if a timezone is valid.

Anyway, I am not against removing timezones. If that solution it is easier, then I would go ahead and evaluate later (if needed). As you said, we offer a lot of timezones.