That would provide the machine readable version... but not the human documentation of time. You wouldn't be able to debug the Moroccan Ramadan rule (which is provided as some elisp code) and its predictions for future changes.<p>Having it be managed by governments would mean that the whim of a politician could break things by changing the established name... say from "US/Pacific" to "USA/Pacific" or deciding by fiat to change the timezone for a political enclave within another one that <i>doesn't</i> have a TLD. ( <a href="https://github.com/eggert/tz/blob/main/northamerica#L821" rel="nofollow">https://github.com/eggert/tz/blob/main/northamerica#L821</a> )<p>This <i>also</i> describes the compromises in the design of the system to accurately record the time.<p><pre><code> # From Paul Eggert (2026-03-07):
# The law says that 21 hours after the usual 2026-03-08 02:00 switch from
# PST to PDT, the next day inaugurates the new standard time Pacific Time,
# i.e., just one clock change but two name changes separated by 21 hours.
# PT, the obvious abbreviation for Pacific Time, is one letter too short
# to conform to TZDB’s (and POSIX’s) [-+[:alnum:]]{3,6} requirements.
# I asked the BC government for advice, with no response. For now, do this:
# 1. As a temporary hack, pretend that the BC law takes effect
# not on 2026-03-09 at 00:00, but on 2026-11-01 at 02:00.
# This pretense works around a limitation in CLDR v48.1 (2026-01-08),
# which would otherwise say the interval uses “Pacific Standard Time”.
# (Below, this temporary hack is marked “Temporary hack; see above.”)
# Strictly speaking this hack is incorrect since the interval uses
# standard time, but it does have the right UT offset and it
# works around the CLDR limitation. We should be able to remove
# the temporary hack after CLDR is fixed.</code></pre>