On 2021-10-03 09:47, Stephen Colebourne via tz wrote:
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.
Thanks for the clear presentation of the issues for persistent data storage! 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. Not even Africa/Asmera can be equated with Africa/Asmara when tzdb does not guarantee that Africa/Asmera will always remain to be linked to Africa/Asmara in the future as long as it exists. In fact, among the timezone names that were merged since 2013, two have been "unmerged" in the meantime (São_Tomé and Juba). Database systems are used to store consistent sets af data over decennials; hence they can only exploit invariants of tzdb that are guaranteed to hold across many releases. The local time scale offsets are modeled in SQL as "nondeterministic" data; these are expected to vary over time and cannot be used in constraints and thus cannot affect data consistency. Most of the guarantees made by tzdb seem to be subject to change in the next release, not just the "merges". 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 (and it is *hard* to check when it indicates which). If a database system relied on the earlier definition, they had a serious problem convincing Irish users that "summer time" is used in winter. So it appears that the tzdb data description does not make any long time guarantees except for standardized names for locations, and one or two local time scales for each location. (And that certainly is a praiseworthy feat and deserves our utmost respect!) The second local time scale (the one in /backzone), if any, is probably the better guess of the local time scale at the location indicated by its name, but that is not guaranteed either. Actually, it is not even true that the two time scales always agree after 1970, although most people seem to believe otherwise. So I think that database system providers can exploit tzdb only by using (practically all) the tzdb timezone names, without any "merging", and selecting for each of them one of the two local time scale definitions, as they see fit. In my opinion, this "cherry picking" is necessary and becomes more difficult when more time scale definitions are moved to backzone, and unnecessarily so. Michael Deckers.