scolebourne at joda.org
Thu Aug 29 11:34:14 UTC 2013
It seems like there are conflicts in the principles behind the tzdb.
Here are my thoughts:
What is the tzdb?
- widely used
- accurate post-1970
- handles changes occurring now
- 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
- 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?
- 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.
More information about the tz