[tz] [PROPOSED] Merge timezones that are alike since 1970

[David Patte]

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'.
>
>