On Thu, 30 Sept 2021 at 10:10, Stephen Colebourne via tz <tz@iana.org> wrote:

On Thu, 30 Sept 2021 at 09:42, Jürgen Appel via tz <tz@iana.org> wrote:

...

a) Although possibly a boundary case, I'd like to add that when using location based identifiers, for past or future times, a unique conversion from local time to UTC is sometimes impossible:

2020-10-25 02:30:00 Europe/Copenhagen cannot be mapped unambiguously to UTC, whereas the reverse mapping works of course. I am not aware of any software that takes this into account.

FYI, java.time.* and Joda-Time provide explicit tools for developers to manage gaps and overlaps on the local timeline.

Ditto Noda Time <https://nodatime.org>, the library for .NET The .NET standard library provides tools to *check* for gaps and overlaps, but isn't quite as insistent on the user being aware of the possibility as Noda Time is.

...

Therefore a reasonable requirement from the downstream user side would be to convey information about such conditions ('invalid time' , 'ambiguous time', evtl. also 'unconfirmed tzdata' for times not covered in the database)

From my perspective as a software library author, handling of these two use cases belong at the downstream library/consumer level, not at the TZDB level.

Indeed - the required data for invalid/ambiguous time is already available in the database; it just needs to be presented appropriately. The "unconfirmed tzdata" is slightly trickier, and I'm not sure what most libraries do about that. Jon

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.

Paul Eggert via tz <tz@iana.org> writes:

Yes, others have proposed this, notably Russ Allbery in <https://mm.icann.org/pipermail/tz/2021-September/030518.html>. It's not clear, though, whether merely adding this level of indirection would be worth the cost. It wouldn't remove political concerns, for example. Nor would it address Zone splits any better than the current approach does.

Although it might be worth adding abstract IDs to implement a larger project, I'd like to see that larger project's outlines before opining.

I think it would be useful primarily if it made sense to hand off the political concerns to a different body that had the infrastructure to apply more political rules to making decisions (assuming that's considered appropriate). The Unicode CLDR, for example (although I have no idea if they want that duty). It handles zone splits better in the specific sense that it separates naming from adding the data and makes it uncontroversial to add a new abstract ID with different rules. It doesn't make it any easier to decide what to call that zone (if anything; it would be possible to have abstract zones that have no names), and where the existing name should point, which seems to be where most of the political disputes lie. It just enables those decisions to be made by a different party. If there's no desire to hand off the naming portions to a different body, the level of indirection may not serve any useful purpose. It does make it easier for different groups to maintain different sets of names while sharing the same underlying data, but that results in inconsistent behavior for users despite using the same name, which is presumably undesirable. (That's currently happening right now, however, and to a lesser extent happens if backzone is included in the data set.) -- Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

On Oct 2, 2021, at 3:02 PM, Stephen Colebourne via tz <tz@iana.org> wrote:

The point above is documenting how things *are*. Business applications and calendaring systems really do store the local date/time and zone ID from TZDB for future events. This works precisely because there are enough IDs provided by TZDB to make this work.

If we're talking about *future* events, the only IDs that would be required to make this work would be IDs corresponding to regions that differ in dates and times after the earliest date and time that matters to the business application in question. And any business application (I'm including calendaring systems in the category of "business application" here) that uses the tzdb couldn't have done so before the tzdb was first released (which was 14-15 years after 1970) - an application could not have, in 1963, have recorded an event scheduled for 1965 as a date/time and zone ID from tzdb. So it's not as if there was an *inherent* need for Europe/Oslo as a tzdb ID to make these applications work; if there had never been a Europe/Oslo ID, and Norwegian locations had used Europe/Berlin, that would have been sufficient to, for example, record future events taking place in Norway. The reason why we would continue to have a Europe/Oslo ID even if we put Norway into the Europe/Berlin tzdb region is for *backwards compatibility* with applications that have, for example, stored future events with a tzdb ID of Europe/Oslo.

Hi, I'm struggling to understand the relevance of the below.  For one, there exists a link for Europe/Oslo that accurately reflects the GMT offset in Oslo at this moment.  For another, the same sort of contract could be made for Piscataway, NJ, or Niemes. Fr, for which there are no specific TZ definitions.  Help me understand your point. Eliot On 03.10.21 11:47, Stephen Colebourne via tz wrote:

On Sun, 3 Oct 2021 at 00:29, Guy Harris via tz <tz@iana.org> wrote:

...

So it's not as if there was an *inherent* need for Europe/Oslo as a tzdb ID to make these applications work; if there had never been a Europe/Oslo ID, and Norwegian locations had used Europe/Berlin, that would have been sufficient to, for example, record future events taking place in Norway. Here is a not untypical legal contract: https://www.sec.gov/Archives/edgar/data/1308106/000119312512368196/d401408de... "NIBOR means that the rate for an interest period will be the rate for deposits in Norwegian Kroner for a period as defined under Bond Reference Rate which appears on the Reuters Screen NIBR Page as of 12.00 noon, Oslo time"

The 100% correct way to represent this in a business application is to define an ID scheme that includes an ID for "Oslo time" and then keep a constantly updated mapping from that ID to the actual zone used in Oslo.

In practice, most business applications/companies would find that very expensive and cumbersome to maintain by themselves. Instead, most business applications simply use "Europe/Oslo" to represent the concept. Effectively, this outsources both the ID and the upkeep of the mapping to tzdb.

Feel free to say that the business applications are doing it wrong. Feel free to say that this shouldn't be tzdb's issue to solve. But my answer will be the same - that no longer matters because this *is* how tzdb IDs are actually used. And in practice it has worked pretty effectively for many years across much of the planet.

And IMO, if tzdb had never published an ID for Oslo, somebody somewhere would have had to invent such a thing - either internal inside lots of companies, or a separate non-tzdb open source project. ie. that there is an inherent need is demonstrated by actual usage.

thanks Stephen

On Oct 4, 2021, at 4:00 PM, Stephen Colebourne via tz <tz@iana.org> wrote:

On Sun, 3 Oct 2021 at 12:53, Eliot Lear via tz <tz@iana.org> wrote:

...

For another, the same sort of contract could be made for Piscataway, NJ, or Niemes. Fr, for which there are no specific TZ definitions.

And Guy asks

...

So what do those applications due for contracts that refer to "Frankfurt time"?

So, it turns out that there is, I believe, a critical difference here between the US view of timezones and the European one. In the US, timezones do not follow the boundary of the whole country, nor even States.

Canada, Australia, Russia, and Brazil, possibly among others, say "hi!" The world does not consist solely of "the United States" and "Europe". (And part of Russia is in Europe - and it has at least two European tzdb regions, Europe/Kaliningrad and Europe/Moscow.)

In Europe, by contrast, timezone boundaries are very much driven by country boundaries.

Except where they aren't.

Thus the answer for Frankfurt is that applications use the zone ID associated with the country, Europe/Berlin,

So those applications have some mechanism to map "Frankfurt" to "Europe/Berlin". *If* that mechanism maps "Frankfurt" to "Germany" and then maps "Germany" to "Europe/Berlin", that works... for Europe. There are places where it won't work.

and applications accept that this is not actually "Frankfurt Time", but a good enough approximation. (Same with Nimes and Europe/Paris). Because there are a limited set of countries, which (almost) all have an associated tz ID and zone rules only change at the country-level, this works out just fine.

So applications that use a mechanism as described above for countries outside (Western) Europe will not work in Canada: https://www.sec.gov/Archives/edgar/data/855931/000095012309070801/o58303exv4... "the rate of interest per annum equal to the average annual yield rate for one month Canadian Dollar bankers’ acceptances (expressed for such purpose as a yearly rate per annum in accordance with Section 5.4) which rate is shown on the display referred to as the “CDOR Page” (or any display substituted therefor) of Reuters Limited (or any successor thereto or Affiliate thereof) at 10:00 a.m. (Toronto time) on such day or, if such day is not a Banking Day, on the immediately preceding Banking Day, plus 1.00% per annum," https://www.sec.gov/Archives/edgar/data/1042682/000104746902008250/a2096324z... "1.1.20 "Bankers' Acceptance Discount Rate" means (i) in respect of Bankers' Acceptances to be purchased by the Lenders which are Schedule I banks under the Bank Act (Canada), the average rate for Canadian Dollar bankers' acceptances having Designated Periods of 1, 2, 3 or 6 months quoted on Reuters Service, page CDOR "Canadian Interbank Bid BA Rates" (the "CDOR Rate"), having an identical Designated Period to that of the Bankers' Acceptance to be issued on such day, (ii) in respect of Bankers' Acceptances to be purchased by the Lenders which are Schedule II banks under the Bank Act (Canada) or Schedule III banks under the Bank Act (Canada) which are not subject to the restrictions and requirements referred to in Section 524(2) thereof and in respect of Discount Notes, the rate for Canadian Dollar bankers' acceptances quoted by the BA Schedule II Reference Lender, having an identical Designated Period to that of the Bankers' Acceptance to be issued on such day, and (iii) in respect of Discount Notes to be purchased by Caisse centrale Desjardins, the annual discount rate established by Caisse centrale Desjardins in accordance with its normal practice as corresponding to the "all-in cost", expressed as a rate per annum and calculated at approximately 10:00 a.m. (Montreal time) on the date of issue of such Discount Notes, to Caisse centrale Desjardins to provide fixed rate loans denominated in Canadian Dollars to be made for a comparable term as that for which such Discount Notes are to be issued and in an amount approximately equal to the face value of the Discount Notes to be then issued by Caisse centrale Desjardins as a part of such issue; the whole having regard to the costs and charges to Caisse centrale Desjardins in obtaining matching deposits in Canadian Dollars in an amount sufficient to fund such fixed rate loans and for a comparable term, together with all other costs and charges (other than internal costs and charges) incidental thereto including the imputed costs of any primary, secondary or other reserves or special deposits required to be maintained in the circumstances; provided that the rates referred to in clauses (ii) and (iii) above may not exceed the rate determined under paragraph (i) by more than 10 basis points (.10%) (in each of cases (i), (ii) and (iii), the "Discount Rates"). In all cases, the Discount Rates shall be quoted at approximately 10:00 A.M. (Montreal time) on the Acceptance Date calculated on the basis of a year of 365 days." https://www.sec.gov/Archives/edgar/data/1163279/000116327902000002/ex1022.ht... ""Expiry Time" means the earlier of: (i) 4:30 p.m. (Vancouver time) on the Due Date; and (ii) 4:30 p.m. (Vancouver time) on the fifth Business Day after the Qualification Date;" or Australia: https://www.sec.gov/Archives/edgar/data/1564708/000119312520027351/d822982de... "BBSY Rate for a period means the higher of zero and the following rate determined at or about 11.00am (Sydney time) on the first day of that period (or if different the time specified by the Facility Agent as the time at which this rate is normally published) and for a period equivalent (in the opinion of the Facility Agent, without the need for instructions) to the Interest Period:" https://www.sec.gov/Archives/edgar/data/869370/000119312504190244/dex21.htm "unless a contrary indication appears, a time of day is a reference to Melbourne time." https://www.sec.gov/Archives/edgar/data/811156/000095012404004125/k87920exv1... "(TIME OF DAY) a reference to time is a reference to Perth time;" or the US: https://www.sec.gov/Archives/edgar/data/1421517/000143774917008029/ex10-1.ht... "Each Advance under the Revolving Credit Loan (each, a ‘Borrowing’) shall be made on notice, given not later than 12:00 Noon (New York time) on the third Business Day prior to the date of the proposed Borrowing in the case of a LIBOR Rate Advance, and not later than 12:00 Noon (New York time) on the date of the proposed Borrowing in the case of a Base Rate Advance, by Borrower to Lender. Unless otherwise agreed in writing by Lender, each such notice of a Borrowing shall be by telephone, confirmed immediately in writing (by telecopier, e-mail or otherwise as permitted hereunder), substantially in the form of Exhibit C (a ‘Notice of Borrowing’), specifying therein the requested (i) date of such Borrowing, (ii) Type of Advance comprising such Borrowing, (iii) aggregate principal amount of such Borrowing, and (iv) the Interest Period, in the case of a LIBOR Rate Advance. Each Borrowing (including any Conversion or Continuation) shall be in an amount equal to One Million Dollars ($1,000,000) or a whole multiple of Five Hundred Thousand Dollars ($500,000) in excess thereof." https://www.sec.gov/Archives/edgar/data/1835256/000119312521052538/d90982dex... "1.6 Time References. Unless the context of this Agreement or any other Loan Document clearly requires otherwise, all references to time of day refer to Pacific standard time or Pacific daylight saving time, as in effect in Los Angeles, California on such day. ..." https://www.sec.gov/Archives/edgar/data/1001039/000110465916088718/a16-1412_... "“Eleventh District Cost of Funds Rate” means, with respect to any Interest Determination Date specified below (an “Eleventh District Cost of Funds Interest Determination Date”), the rate equal to the monthly weighted average cost of funds for the calendar month immediately preceding the month in which the Eleventh District Cost of Funds Interest Determination Date falls as set forth under the caption “11th District” on the display on Reuters (or any successor service) on page COFI/ARMS (or any other page as may replace the specified page on that service) (“COFI/ARMS Page”), or if not so displayed, on Bloomberg service (or any successor service) on page ALLX COF (or any other page as may replace the specified page on that service) (“Bloomberg page ALLX COF”) in each case, as of 11:00 A.M., San Francisco time, on the Eleventh District Cost of Funds Interest Determination Date. If such rate does not appear on the COFI/ARMS Page or Bloomberg Page ALLX COF on any related Eleventh District Cost of Funds Interest Determination Date, the Eleventh District Cost of Funds Rate for the Eleventh District Cost of Funds Interest Determination Date will be the Eleventh District Cost of Funds Rate Index, as defined below. If the FHLB of San Francisco fails to announce the rate for the calendar month next preceding the Eleventh District Cost of Funds Interest Determination Date, then the Eleventh District Cost of Funds Rate for that date will be the Eleventh District Cost of Funds Rate in effect on that Eleventh District Cost of Funds Interest Determination Date."

For the US, tzdb actually provides less ability to solve this problem. Even if tzdb had an ID for each State, that would be insufficient to cleanly map a location to a good enough ID. In the US, tzdb effectively doesn't help a user find itz info for Piscataway, NJ - something must *directly* connect Piscataway with America/New_York - no other geographic hierarchy such as the State will do.

ie. in Europe, you can map location to country (typically easy to do) and then country to timezone ID (easy) and be happy with the outcome. In the US, you would need a direct mapping from location to timezone for thousands of locations because there is no suitable intermediate location hierarchy. An abstract region model is the only one that really works for the US.

What's the difference between "map location to country" and "map location to tzdb ID" that renders the former "easy to do" in Europe but that renders the latter *not* easy to do in Europe? Is it that the former doesn't need direct mapping from location to country, so that even with a larger number of cities in Europe, you wouldn't need a table that gives the country for all of those cities?

Why does this matter in this discussion? Well, one thing I don't want to see in tzdb is an attempt to force the US model onto Europe. The extra level of country implicit in the European zone IDs is really useful to applications.

So either 1) you're expressing concern for applications that *only* have to deal with times in "Europe" in the sense of "that region on the Eurasian continent where countries don't have more than one tzdb region" or 2) you're expressing concern for application that use *different* algorithms for selecting tzdb IDs to represent "XXX Time", where the algorithm used to map between "XXX Time" and a tzdb region is "map XXX time to a country and then map that country to a tzdb region", and don't want those applications to have to come up with a different algorithm for Europe.

And part of this discussion is to tease out the implicit and make it explicit.

Which is exactly what I've been doing in the past couple of messages. So, let's make it explicit in which regions of the world it's important that "map "XXX Time" to a country and map a country to a tzdb region" must work, with the rest of the world possibly using "map "XXX time" directly to a tzdb region" (an algorithm that would *also* work for Europe).

On Oct 5, 2021, at 12:54 AM, Clive D.W. Feather <clive@davros.org> wrote:

So do Cyprus, the Kingdom of Denmark, France, the Kingdom of the Netherlands, Portugal, and Spain.

In which case, for example, let's hope no sufficiently notable financial institution has a significant office in the Canary Islands or Melilla, so that the city-to-tzdb-ID mapping algorithm doesn't have to cope with Las Palmas de Gran Canaria Time, Santa Cruz de Tenerife Time, or Melilla Time - *maybe* the existence of Africa/Ceuta will make the algorithm work for "Ceuta Time" if it also tries {Continent}/{tzdb-ID-ification of city name}. (A quick search of sec.gov doesn't find any of those, so *maybe* an "XXX Time" -> country -> tzdb region mapping will work for Spain.)

On Oct 3, 2021, at 2:47 AM, Stephen Colebourne via tz <tz@iana.org> wrote:

On Sun, 3 Oct 2021 at 00:29, Guy Harris via tz <tz@iana.org> wrote:

...

So it's not as if there was an *inherent* need for Europe/Oslo as a tzdb ID to make these applications work; if there had never been a Europe/Oslo ID, and Norwegian locations had used Europe/Berlin, that would have been sufficient to, for example, record future events taking place in Norway.

Here is a not untypical legal contract: https://www.sec.gov/Archives/edgar/data/1308106/000119312512368196/d401408de... "NIBOR means that the rate for an interest period will be the rate for deposits in Norwegian Kroner for a period as defined under Bond Reference Rate which appears on the Reuters Screen NIBR Page as of 12.00 noon, Oslo time"

https://www.sec.gov/Archives/edgar/data/1524472/000152447218000006/xyl123120... "Base Rate means for any Loan or Unpaid Sum in EUR the EURIBOR Screen Rate as at 11.00 a.m. (Frankfurt time), on the relevant Rate Fixing Day for such currency for a period equal in length to the Interest Period of that Loan or Unpaid Sum and, if any such rate is below zero, the Base Rate will be deemed to be zero." And: # # This is a directory into which the 2021a lz-compressed tarball was unpacked # # We look for a tzid corresponding to Oslo in a source file # $ egrep '/Oslo' * | egrep -v 'backzone|to2050.tzs|tzdata.zi|zone.tab|zone1970.tab' backward:Link Europe/Oslo Atlantic/Jan_Mayen europe:Zone Europe/Oslo 0:43:00 - LMT 1895 Jan 1 europe:# All these events predate our cutoff date of 1970, so use Europe/Oslo europe:Link Europe/Oslo Arctic/Longyearbyen # # There is one. # # Now we look for a tzid corresponding to Frankfurt in a source file # $ egrep '/Frankfurt' * | egrep -v 'backzone|to2050.tzs|tzdata.zi|zone.tab|zone1970.tab' $ # # There isn't one. #

The 100% correct way to represent this in a business application is to define an ID scheme that includes an ID for "Oslo time" and then keep a constantly updated mapping from that ID to the actual zone used in Oslo.

In practice, most business applications/companies would find that very expensive and cumbersome to maintain by themselves. Instead, most business applications simply use "Europe/Oslo" to represent the concept. Effectively, this outsources both the ID and the upkeep of the mapping to tzdb.

So what do those applications due for contracts that refer to "Frankfurt time"?

On 10/3/21 1:58 PM, Michael H Deckers via tz wrote:

    From the viewpoint of SQL database system providers, one cannot     "merge" Europe/Oslo with Europe/Berlin because tzdb does not     (and can not) guarantee that they remain the equal in the     future.

That's OK and there's longstanding precedent for that sort of thing, as database users should not "merge" Europe/Vatican to Europe/Rome for the same reason, even though the former is a Link and the latter a Zone in tzdb. This issue predates and is largely independent of whether out-of-scope pre-1970 Zones should be merged within tzdb itself.

    For instance,     the dst bit used to indicate "summer time" for about 20 years,     but since 2018a, the dst bit could also indicate winter time

If this is talking about so-called "negative DST" where the UT offset with is_dst is less than the UT offset without, then "winter time" is in general a misnomer as the phenomenon can occur in summer (e.g., Morocco) as well as in winter (e.g., Ireland). And negative DST has been been required by POSIX and supported by tzcode for decades; the only new thing circa 2018 is that this longstanding feature began to be used in tzdata.

    it is not even true that the two time scales     always agree after 1970, although most people seem to believe     otherwise.

If there are counterexamples please suggest fixes, preferably in 'git format-patch' form. Although 'backzone' is documented to be less reliable, we're certainly open to fixes from the community.

On 10/2/21 3:02 PM, Stephen Colebourne via tz wrote:

An abstract region represents a part of the Earth that has had the same clock rules since 1970. At some point prior to 1970 different locations within the abstract region had different clock rules, even if that was just LMT.

Thanks, I understand that notion better now.

...

...

3) "An event will happen at this time in the future" If an end-user wants to store an event in the future, eg. a one hour meeting next month, the correct approach is to store the date, time and zone ID

That doesn't suffice, as it doesn't work if the Zone splits in the meantime.

Of course that is true. But this hasn't been a problem in practice for business applications AFAICT.

If we could ignore problems as significant as Zone splits, we would have a lot of leeway. As you suggested earlier, we could even discard all pre-1970 data, as that would be less of a practical problem than Zone splits are. However, I doubt whether Zone splits are that easy to ignore. Granted, Zone splits don't happen every day - I think the most recent one was in 2018 when Asia/Qyzylorda hived off Asia/Qostanay. However, I expect that the roughly 800,000 people in the newly-created Zone had generated a fair number of affected timestamps in their business planning and scheduling.

by providing separate IDs like Europe/Oslo and Atlantic/Reykjavik for many years, TZDB has provided the basic tools necessary for business applications to function in the way described above.

Sure, and those IDs are still there and still supported. I think we agree that IDs like Europe/Oslo should continue to exit.

IMO, it is important to ensure that IDs exist for such shared zones. But luckily enough we already have "US/Mountain" and "CET", so the ID part is already sorted (in the US and EU).

Unfortunately even that is not sorted. There's a good chance that neither "US/Mountain" nor "CET" will work the way users might expect, if the US and Europe change time zone rules in ways that are seriously being discussed by political leaders. For example, suppose a few US/Mountain locations (just Idaho, say) decide to continue with current US/Mountain rules while most US/Mountain locations switch to CST (something that tzdb currently has no Zone for). In that case, if we had only Zones like "US/Mountain" we'd be asking most users to change their TZ settings, which'd be worse than the current system where "America/Denver" should continue to work for most users. Originally, tzdb started out with zones like "US/Mountain" and "CET". However, when I added data for the rest of the world, I discovered that the old approach didn't generalize well to places less centralized than US and the EU. It was stretching to even apply that old scheme to Australia, where different states in the same time zone sometimes (but not always) use different DST rules. I didn't offhand see how to apply the old approach to Russia (which uses a different system mostly unknown in the West, and which was chaotic in the 1990s), much less Africa, the Pacific, etc. I'm not saying it couldn't have been done (at least in theory) given enough time and research into all the legal definitions of time, but the time wasn't available and the research has never been done.

While I can understand the conceptual desire to have TZDB only provide abstract regions, it seems completely impractical to do so at this point

I agree, as mentioned above. For compatibility reasons we should provide names like Europe/Oslo into the indefinite future. If this isn't already clear in the guidelines it'd be good to make it clear.