Thanks for these two lists. I think that they cover the users and use cases pretty well. These can be used with my list to get a sense of who might be affected by any changes that are made. Stephen On Sat, 2 Oct 2021 at 03:08, Paul Eggert via tz <tz@iana.org> wrote:
Thanks for starting this discussion. I looked at your email’s subject line and wrote up some thoughts about the stated topic, as I figured it’d be good to think independently at first so that we could see two fresh approaches. Here are those thoughts. (I will comment on your email more directly in a followup message.)
-----
Knowing one’s users is important when thinking about use cases, so I’ll start by listing tzdb users, as follows. This list is in no particular order and is surely incomplete.
* End users who don’t want to worry about timestamp conversion. They want conversion between UT and local time to work correctly with a minimum of fuss.
* Administrators who set up default timezones for sets of devices under their administration.
* Users or downstream projects that care only about leap seconds (notably, NTP users consuming the leap-seconds.list file).
* Downstream projects that package TZif files for delivery to their users as part as OS releases or patches.
* Downstream projects that communicate TZif files or other TZDB-derived data to their users via TZDIST (Internet RFC 7808) or other network protocols.
* Downstream projects that translate TZif files into some other format, that is then communicated to their users.
* Downstream projects that translate tzdb source files into some non-TZif format, which is then communicated to their users somehow.
* Downstream projects that produce timezone choosers (programs that let user choose a timezone setting), either via global positioning, or selecting from a map, or selecting via a textual interface.
* Downstream projects that produce fancier interfaces, such as extracting timezone histories, comparing two timezone histories, and examining tzdb’s own history.
* Downstream projects that infer metadata from the tzdb source code, metadata that are not explicit in the source.
* Downstream projects that use tzcode.
* Governments that change timezone rules and need to have tzdb updated.
* Humans reading tzdb source files, for understanding of timezone history.
* Timezone historians who might find corrections to old data, or who might find old data not currently present in the database.
* Activists who want governments to change timezone rules.
* Activists who want tzdb to highlight their concerns.
* Researchers who study the timezone data and its evolution as interesting objects in their own right.
* Maintainers who have limited resources to accommodate all the above.
Given the above, here are some use cases. This list also is in no particular order and is surely incomplete.
* Convert near-future or near-past timestamps.
* Convert far-future or distant-past timestamps.
* Select which timezone to use, either by default or for an individual conversion.
* Determine what the conversion rules are, e.g., what rules are used for spring-forward and fall-back.
* Assess conversion accuracy.
* Determine the source of the data used for conversions.
* Assess the consensus level of timezone data, since in some cases the rules were significantly disputed by the people in charge of clocks at the time. Also, rules may be disputed now by timezone historians.
* Patch a distributed tzdb for use further downstream.
* Update a local copy of tzdb because of a new tzdb release or patchset.
* Respond to queries about why tzdb is the way it is.
* Update conversion of previously-converted timestamps after tzdb changes.
* Update tzdb because governments changed the rules.
* Update tzdb because errors were found.
* Update tzdb because data entries are dubious or disputed.
* Update tzdb because it unfairly discriminates (or appears to discriminate) in favor of some countries, ethnic groups, etc.
* Update downstream code from tzcode, even if the downstream code has been patched.
* Update a downstream database that contains tzdb data, perhaps in a different form and perhaps with a superset of a subset of tzdb, and perhaps patched in its own way.
* Derive different versions of timezone data for different needs.