A recent issue report and the introduction of MSFS prompted me to review AIFP's handling of timezones.
Flightsim airport name data includes four fields: Country, Region, City and airport Name. AIFPs Timezone_Base.dat (on which your Timezone.dat file is based) provides a UTC offset for every country, region and, where necessary, city referred to in FlightSim's stock airport data. The process is simple. When AIFP needs to determine the timezone for an airport, it looks for the Country in Timezone.dat. It then searches within the country data for the airport's Region. If the Region is not found then the timezone offset for the country is used. Otherwise, AIFP searches within that Region's data for the specified City. If found, the City's timezone is used; if not AIFP uses the Region timezone.
Prior to my recent review, there were only a handful of stock airports FS9->PV5 for which no timezone was found. Now there are none. What can't be so easily determined is whether or not the computed timezone is correct. Given the very small number of complaints, I am, perhaps naively, assuming most are accurate. (As always. If you find erroneous data, let me know and I'll attempt to fix it. Also, please remember, there's a Timezone Editor available to fix it yourself. So you don't have to wait for me.)
But, be aware, add-on airports add a "wrinkle". So long as add-on developers consistently use the same naming scheme as the stock airports, all is well. But, change a single character and timezone calculation may no longer work. New add-on airports (i.e. for which there is no stock equivalent) will always require a Timezone.dat update if the naming data cannot be resolved with the current file. If AIFP is unable to find the timezone offset for an add-on airport, compare the respective name data of the two airports and, with the Timezone Editor, create a new entry for Timezone.dat to handle the addon. Since there are no rigid constraints on add-on airport naming, it is not possible for AIFP to "foresee" what developers might use.
The current General Release is primarily intended to increase compatibility with MSFS, so I also reviewed timezone calculation with MSFS. What I found was that thousands of airports could not be matched. Fortunately, most turned out to be due to different spellings of the Country name (French vs. English). By adding the Country spelling used by MSFS to Timezone.dat, I was able to fix the majority of those issues. But, Asobo has also chosen to materially deviate from the earlier airport naming scheme and seems to have abandoned providing the Region entry for new airports. Without regional data, AIFP has no basis whatsoever for determining the timezone of an individual airport within a country having more than one timezone, necessitating a Timezone.dat entry for every airport. This is impractical; MSFS has over 40000 stock airports! Even just considering the new countries (there are over 700 new Russian airports) would require an excessive amount of effort in just researching the associated timezone data - compared to the relatively minor effort of an individual user who might only be interested in a few of them. The same situation applies to the Democratic Republic of Congo for which there are over 100 airports spanning 2 timezones.
As well, Asobo has chosen to collect some of it's new airports into country "groups". Several of these groups are problematic, e.g., "Kazakhstan/Kyrgyzstan" which spans two timezones and "Kiribati/tuvalu" which spans 3. Once again, AIFP has no basis whatsoever for determining timezone.
Given the current issues with MSFS re .bgl-generated AI traffic, I doubt anyone will care much about these 1000 or so airports for which no timezone information is currently available. But should that ever get sorted out, and someone can prevail upon Asobo to reinstate regional name data for MSFS' stock airports, AIFP will be able to provide more satisfactory service.
I expect to make a new AIFP General Release over the next few days (essentially Development Release 3.4.3.14(c) renamed to 3.4.3.15). It will include an updated TimeZone_Base.dat.
Once you have installed the new general release, if you have not made any timezone changes, just delete Timezone.dat and restart AIFP. AIFP will copy Timezone_Base.dat into Timezone.dat. Unfortunately, there's no simple way to update Timezone.dat if you have already added your own updates. (Timezone_Base.dat was intended to be only a "starter set". ) In that case, rename Timezone.dat, restart AIFP (to re-create Timezone.dat) and then reapply the changes from the renamed Timezone.dat. Most users will want to use the Timezone Editor. Alternately, close AIFP and re-apply the changes directly to Timezone.dat with a text editor, ensuring you place them as they were in the previous version of the file. If you make a mistake, just delete Timezone.dat and start over.
But, please be reminded, you will still need a custom entry in Timezone.dat for add-on airports that don't fully conform to the original FS airport naming scheme.
Don
Flightsim airport name data includes four fields: Country, Region, City and airport Name. AIFPs Timezone_Base.dat (on which your Timezone.dat file is based) provides a UTC offset for every country, region and, where necessary, city referred to in FlightSim's stock airport data. The process is simple. When AIFP needs to determine the timezone for an airport, it looks for the Country in Timezone.dat. It then searches within the country data for the airport's Region. If the Region is not found then the timezone offset for the country is used. Otherwise, AIFP searches within that Region's data for the specified City. If found, the City's timezone is used; if not AIFP uses the Region timezone.
Prior to my recent review, there were only a handful of stock airports FS9->PV5 for which no timezone was found. Now there are none. What can't be so easily determined is whether or not the computed timezone is correct. Given the very small number of complaints, I am, perhaps naively, assuming most are accurate. (As always. If you find erroneous data, let me know and I'll attempt to fix it. Also, please remember, there's a Timezone Editor available to fix it yourself. So you don't have to wait for me.)
But, be aware, add-on airports add a "wrinkle". So long as add-on developers consistently use the same naming scheme as the stock airports, all is well. But, change a single character and timezone calculation may no longer work. New add-on airports (i.e. for which there is no stock equivalent) will always require a Timezone.dat update if the naming data cannot be resolved with the current file. If AIFP is unable to find the timezone offset for an add-on airport, compare the respective name data of the two airports and, with the Timezone Editor, create a new entry for Timezone.dat to handle the addon. Since there are no rigid constraints on add-on airport naming, it is not possible for AIFP to "foresee" what developers might use.
The current General Release is primarily intended to increase compatibility with MSFS, so I also reviewed timezone calculation with MSFS. What I found was that thousands of airports could not be matched. Fortunately, most turned out to be due to different spellings of the Country name (French vs. English). By adding the Country spelling used by MSFS to Timezone.dat, I was able to fix the majority of those issues. But, Asobo has also chosen to materially deviate from the earlier airport naming scheme and seems to have abandoned providing the Region entry for new airports. Without regional data, AIFP has no basis whatsoever for determining the timezone of an individual airport within a country having more than one timezone, necessitating a Timezone.dat entry for every airport. This is impractical; MSFS has over 40000 stock airports! Even just considering the new countries (there are over 700 new Russian airports) would require an excessive amount of effort in just researching the associated timezone data - compared to the relatively minor effort of an individual user who might only be interested in a few of them. The same situation applies to the Democratic Republic of Congo for which there are over 100 airports spanning 2 timezones.
As well, Asobo has chosen to collect some of it's new airports into country "groups". Several of these groups are problematic, e.g., "Kazakhstan/Kyrgyzstan" which spans two timezones and "Kiribati/tuvalu" which spans 3. Once again, AIFP has no basis whatsoever for determining timezone.
Given the current issues with MSFS re .bgl-generated AI traffic, I doubt anyone will care much about these 1000 or so airports for which no timezone information is currently available. But should that ever get sorted out, and someone can prevail upon Asobo to reinstate regional name data for MSFS' stock airports, AIFP will be able to provide more satisfactory service.
I expect to make a new AIFP General Release over the next few days (essentially Development Release 3.4.3.14(c) renamed to 3.4.3.15). It will include an updated TimeZone_Base.dat.
Once you have installed the new general release, if you have not made any timezone changes, just delete Timezone.dat and restart AIFP. AIFP will copy Timezone_Base.dat into Timezone.dat. Unfortunately, there's no simple way to update Timezone.dat if you have already added your own updates. (Timezone_Base.dat was intended to be only a "starter set". ) In that case, rename Timezone.dat, restart AIFP (to re-create Timezone.dat) and then reapply the changes from the renamed Timezone.dat. Most users will want to use the Timezone Editor. Alternately, close AIFP and re-apply the changes directly to Timezone.dat with a text editor, ensuring you place them as they were in the previous version of the file. If you make a mistake, just delete Timezone.dat and start over.
But, please be reminded, you will still need a custom entry in Timezone.dat for add-on airports that don't fully conform to the original FS airport naming scheme.
Don