On 1/20/18 11:08, John Hawkinson wrote:
I also concur that there have been a lot of destabilizing changes in the tz database in recent years and that they seem to me like a not-very-good idea. Many of these changes would be fine if we had been starting from scratch and it was the first release, but we're not, and so they are not.
(Relatively unimportantly, I particularly wonder at the effect of changes that adjust the historical rules of some zones from long ago, as we decide Shanks was wrong, etc. If anyone in such a zone had files in their filesystem with dates that far back, they would see weird churn and and odd changes relative to more recent timestamps, and I wonder at the wisdom of making those changes.)
--jhawk@mit.edu John Hawkinson
Again this suggests to me that we need to differentiate between the core timezone data - which should be as (historically) accurate as possible - and the data used by services which may well rate stability higher than accuracy. The second can easily be derived from the first either by creating modified copies or by the tools making adjustments. As for the churn in past data - it suggests to me that we should be storing version information along with the dates and ids. That's not going to help data in the past but we should be trying to improve matters moving forward