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.