Adding a "follow"-like syntax is a fine idea. I think it's been proposed before, but not implemented. I would hope that one could use "follow" not only at the end of a Zone, but also within a zone, such as "location X follows location Y from 1950 to 1990". Also, the code should defend itself against follow cycles (e.g., A follows B follows C follows A). Any changes along these lines would be complicated by backward-compatibility concerns, though. That is, we could use a "follow"-like syntax only in vanguard format at first. To give you a feel of how long this can take, we added support for %z in zone abbreviations in 2015f, and we're not using this feature even now in the vanguard data, much less the main data (this is mostly due to my lack of time...).

On 6/14/21 6:42 AM, Alois Treindl wrote:

The reason is my experience with the Shanks database in its software version (not the book variant, which is nearly flat). > That one is full of jumps from one table to the other and back. It is extremely complicated to follow this as a human

I have never used Shanks's software and didn't know that it exposed its tables to users. And although Shanks's books typically use "follow" only at the end of a time table, they sometimes use it earlier to good effect. For example, the Shanks International Atlas (6th edition) has a table for Melbourne which essentially says "use Sydney's table with these few exceptions", and the exceptions are not all at the start which means the Melbourne table has multiple "follow"s.

Readability for humans has to be kept in mind.

Yes, but I expect that readability would be helped by having "follow" within tables so long as it's done reasonably, as the Shanks book does for Melbourne. Part of the issue here is: what is the typical use case? For Shanks's books, the main idea is to present the illusion of a complete set of data for everywhere on the planet, and to make it easy to look up a timestamp history from a location. These books were automatically-generated from more-compact tables that are easier to maintain but harder to read. For tzdb, we don't present the illusion of a complete timezone history for every location; instead the goal is merely to record histories since 1970. Also, the tzdb source consists of easier-to-maintain but harder-to-read compact tables, with the idea that downstream software like 'zdump' can make the tables easier to read as needed. So the goals for tzdb's tables differ from the goals of Shanks's books. In particular, a common scenario in tzdb is for two zones to split: formerly they were identical before 1970, but now they're different. For example, Pacific/Bougainville split from Pacific/Port_Moresby in 2014i. If we had had "follow" back then, I would have wanted to use it to say the equivalent of "Pacific/Bougainville is like Pacific/Port_Moresby before 2014-12-28 02:00, and here's what it looks like afterwards". But I couldn't do that if "follow" is only at the end. Anyway, thanks for contributing the code to implement "follow" at the end; it's provided food for thought and perhaps we can see our way to implementing something along those lines. (Of course at first it would be used only in vanguard format.)

Just in case anyone is interested, my patch for zic.c (from 25 April 2021) is attached. It is in the public domain. On 12.06.21 12:34, Alois Treindl via tz wrote:

I assume the main reason why Paul Eggert wants to merge time zones is the fact there is less maintenance work, if for example EU rules change not only regarding DST, but regarding the standard time.

If something like this happens, multiple zones have to be updated.

Some years ago I developed my own  patch to zic.c to make it understand the new keyword 'follow'.

That way, I can represent a zone which deviates from a TZ "standard zone" before a certain date, and then say 'follow standard zone' at the end of the zone data.

I have completed that for several countries, for example to represent the deviations from Europe/Berlin within parts of Germany before 1949, or to represent the numerous deviations in France from Europe/Paris.

I attach two files which show the application of the 'follow' keyword.

Of course I will be happy to share the patch to zic.c which enables it to process the follow keyword.

As it is now, I apply my patch each time an update of zic.c is published.

If the follow keyword is introduced into the main distribution, it could be used for zones like Europe/Copenhagen which instead of being eliminated would become

Zone Europe/Copenhagen   0:50:20 - LMT     1890                          0:50:20 -      CMT     1894 Jan  1 # Copenhagen MT                          1:00   Denmark CE%sT   1942 Nov  2 2:00s                          1:00   C-Eur   CE%sT   1945 Apr  2 2:00                          1:00   Denmark CE%sT   1950                          0    follow Europe/Berlin

The information that Copenhagen is the same as Berlin after 1949 would be there, as well as the original data.