[tz] Moving more zones to 'backzone'

[Paul Eggert]

On 8/4/22 05:12, Peter Krefting via tz wrote:
> I have been considering switching to global-tz for the next update, but 
> I just realize that it has the same zone1970.tab file as regular tz, so 
> that will not help at all

Yes, that's right. The only difference between global-tz and default 
TZDB is that the former has some Zones that differ only in pre-1970 
timestamps. Global-tz won't help if your app involves post-1970 
timestamps (which is what embedded systems invariably do). The same is 
true for TZDB's new PACKRATLIST option, as it is equivalent to global-tz.


> (I am writing for an embedded system where we 
> cut off old data from before build time, as it does not preserve 
> information across reboots in anything but fully written-out text form).

In that case, even zone1970.tab is overkill for your application, which 
doesn't care about zones that differ only for timestamps in the past.

On my long list of things to do, is to create a file zonenow.tab that 
would cater to systems that need only timestamps now and in the future. 
This table would have fewer entries than zone1970.tab and should be 
significantly easier to use - it will make it easier to "explain to 
users what they get", as you put it, as it's hard to explain regions 
that differ only due to past timestamps.

Although zonenow.tab should be useful it won't suffice in the long run. 
If we assume the sort of timekeeping changes that we've seen in the last 
century or so, in the long run the current maintenance approach will 
likely grow the number of Zones exponentially until it approaches the 
number of locations on the planet. I don't think anybody would want to 
maintain that many Zones. We will need a better approach, one that will 
surely require changes to the format of zic's input and output.