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