NetBSD will continue using Stephen Colebourne's fork - the last "official" release we used was 2021a - before that I simply made the changes that matter to what was 2021a to compensate for changes to zones that correctly affected timestamps, and ignored all the rubbish that was discarding pre-1970 data. Stephen's script and distribution of the results makes that simpler. We will continue using that as long as it is available, and needed, and if the former ceases while the need remains, we'll go back to managing ourselves. While some of the pre 1970 data might not be as accurate as we'd like, most of it is more accurate than having no data at all for the zone, or worse, pretending some other zone's data applies. If the intent was to truly stop caring about anything pre 1970, then you'd remove all of the pre 1970 data from all zones, and make localtime() error out when given a time that produces tm_year < 1970. That would at least be correct (in some sense), if not very useful. If the real reason for this is the workload of dealing with more zones, then simply acquire more helpers - they don't need to be delegated authority to make changes at will, but could easily help with editing changes that you want to make, and making sure that all the zones that should be updated, get updated - it doesn't need to be entirely a 2 man show (and not only would that reduce your workload, it would help train future potential co-ordinators). An enhanced zic (or wholly redesigned) input format, or a pre-processor (though ideally not that) to assist would be a good idea - and if you have someone (or several) helping with the routine (more than just Tim) then maybe you'd have the time to make that happen - that must be more interesting than just editing zone files. The first thing any such helpers should do is to restore all the zones that have been (effectively) removed (shunted into backzone) and make sure that any updates that should have been applied to them are applied. On the other hand, if this is all the "equity" nonsense, then the merges should simply be reversed - all the way back to when they started. I have seen here no arguments at all that justify any merges, not even close. If there are "hidden pressures" those really should be ignored unless those applying that pressure make a case here, in public, for their concerns, that we can agree or disagree with. If you're unable, for whatever reason, to resist something like that - to do nothing unless the change is agreed here, then you really should resign, and allow someone else to take over. kre