But is the backzone data 'frozen'? Is it acceptable to propose corrections to the backzone data when more accurate historical data for a city becomes available? Also Is it possible to add new backzones, even if they may refer to an already existing primary zone? And could the backzones be organized in a way that is more user friendly to its primary users (ahem: always by current ISO country?) I think its clear that historical data is less accurate the further back we go. But for people that are using tz for historical localized timezone information, they already understand that. Historical data is always assumed to be murky, yet hopefully historical data quality improvements in tz are still accepted. I have no problem with merging all the zones in the primary database as suggested for (1), depending how much flexibility tz will accept in backzone enhancement. To me, the two tables provide very different needs to two very different sets of users. Let the O/S teams use table 1, let the history-related app developers use a constantly improving backtable. On 2021-06-01 19:48, Paul Eggert wrote:
On 5/30/21 8:10 AM, David Patte via tz wrote:
1) On one hand, several people would like to simplify the main data table, reducing the number of individual zone records by merging them where they are the same since 1970....
2) On the other hand, several people would like to have tz be a source, maintain and collect more historical tz data and organize it by international standards so the historical data can be expanded per country....
So, I have a question. And I'm not trying to difficult.
Assuming that the goal of (1) is achieved, what can be done to not undermine type 2 users? If we have (1), but also want to maintain and expand historical data per country's zones, how could that be done? using a secondary table? Could the back table be improved, expanded and enhanced?
These are good questions. We have the 'backzone' file for type (2) data, but the 'backzone' approach is apparently unsatisfactory for some users of type (2) data.
Part of the problem may be that 'backzone' is a mishmash quality-wise. Today there are only two simple options in the Makefile - use either all of 'backzone' or none of it - and there are real problems with using all of it. Perhaps we could add something that would give users more flexibility.
For example, if a downstream user wants the 'backzone' entry for Europe/Stockholm which is well-documented, but doesn't want backzone's America/Montreal entry because it's not well-attested and is most likely wrong, the user could specify a list of backzone names that includes Europe/Stockholm but excludes America/Montreal. I think it would not be too much work to add something like this to the tzdb code. This would better support users who want a separate Zone for each country in 'backzone', but do not want all of 'backzone'.