It seems like there are conflicts in the principles behind the tzdb. Here are my thoughts: What is the tzdb? Generally accepted: - widely used - ubiquitous - reliable - accurate post-1970 - handles changes occurring now More controversial: - IDs used in GUIs (they are whether we like it or not) - IDs have meaning (they do whether we like it or not) - pre-1970 is in-scope (data is there whether we like it or not) - pre-1970 data may not be accurate (users like data, care less about its accuracy) - pre-1970 LMT is accurate for the location in the tzdb ID What do end users expect? (developers and non-developers) - users often pick zones based on raw tzdb ID - users don't know the history of zone rules in their location - users do know that they live in an area that might have special zone rules, eg. Busingen/Navajo - users want minimal cognitive effort, pick it and it works - users don't understand the nuances of a cross-border zone, they just associate with their region What do I expect? - Stability - No deletions of data, except where _proven_ wrong - Additions focussed on today and the future - Historical changes only following research - No new time-zones in the main files unless they differ post-1970 - At least one time-zone ID for each ISO-3166 region - Using all files except backward should meet goals above - Backward file is for deprecations only I don't think that any of this is unreasonable, or different from how the tzdb has previously worked. Stephen