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