[tz] TZDB use cases

[Stephen Colebourne]

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