A 1 year expiration date is crazy. Look at the discussion of SAVE; it is impossible to update all devices that consume the data in that timeframe. Most have a mechanism for taking new data, but not new code. Mark On Tue, Feb 6, 2018 at 3:40 PM, Christos Zoulas <christos@zoulas.com> wrote:
Hi,
Here's my 5 cents to the tzdb compatibility discussion:
- Things need to move forward; half-measures like "functional comments" end up hurting in the long term and create unpredictable behavior. - There are other users of the tzdata "source" so compatibility needs to be maintained for "some time". - On the other hand, we can't be held hostage forever; people who write parsers, should be able to maintain the code.
Straw man proposal:
1. Create a version ChangeLog with tzdb; it should be simple: - a version number (for reference) - the release date (to guide expiration) - an explanation to what changed in the format (for parser writers)
2. Maintain two copies of the source; the current one, and the previous version in a "compat" subdirectory. Expire "compat" a year after the release of the next version.
I hope this is helpful,
christos