[tz] TZDB use cases

[Paul Eggert]

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.