tzdata source compatibility
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
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
On Feb 6, 4:51pm, mark@macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?=) wrote: -- Subject: Re: [tz] tzdata source compatibility | 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. This is for the parsers. One would hope that the devices don't parse the tzdata source files! christos
On 6 February 2018 at 16:37, Christos Zoulas <christos@zoulas.com> wrote:
On Feb 6, 4:51pm, mark@macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?=) wrote: -- Subject: Re: [tz] tzdata source compatibility
| 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.
This is for the parsers. One would hope that the devices don't parse the tzdata source files!
Joda-Time is downloaded over 3 and a half million times each month (a conservative estimate). Each copy has a time-zone parser that the downloader can use on the tzdb source files. While the base parser can indeed be fixed for a change, that doesn't fix the millions of copies already downloaded. Stephen
On Feb 7, 12:35pm, scolebourne@joda.org (Stephen Colebourne) wrote: -- Subject: Re: [tz] tzdata source compatibility | Joda-Time is downloaded over 3 and a half million times each month (a | conservative estimate). Each copy has a time-zone parser that the | downloader can use on the tzdb source files. While the base parser can | indeed be fixed for a change, that doesn't fix the millions of copies | already downloaded. | Stephen So if you download new tzdb source files, you need to download a new Joda-Time. In fact if there was a version tag in the tzdb files, Joda-Time could be smart enough to tell you to do it, or do it itself. christos
On Feb 7, 2018, at 8:43 AM, Christos Zoulas <christos@zoulas.com> wrote:
In fact if there was a version tag in the tzdb files, Joda-Time could be smart enough to tell you to do it, or do it itself.
There is a version stamp in the source files (a file named version), and that is exactly what my lib does (except for C++). Howard
On 02/07/2018 07:35 AM, Stephen Colebourne wrote:
On 6 February 2018 at 16:37, Christos Zoulas <christos@zoulas.com> wrote:
On Feb 6, 4:51pm, mark@macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?=) wrote: -- Subject: Re: [tz] tzdata source compatibility
| 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.
This is for the parsers. One would hope that the devices don't parse the tzdata source files! Joda-Time is downloaded over 3 and a half million times each month (a conservative estimate). Each copy has a time-zone parser that the downloader can use on the tzdb source files. While the base parser can indeed be fixed for a change, that doesn't fix the millions of copies already downloaded. Stephene
I don't understand what the big deal is here. I'm all for tzdata being as accurate as possible (both past and future transitions). As Mike Douglass has already stated, if that requires changes to the source data, the data can be filtered into something that is compatible with legacy software. If that means that Paul puts all source data into <region>.new files and then filters that to produce <region>, then so be it. Consumers of the data can choose whichever files they can handle. Legacy software will be none the wiser. -- Ken Murchison Cyrus Development Team FastMail US LLC
participants (5)
-
christos＠zoulas.com -
Howard Hinnant -
Ken Murchison -
Mark Davis ☕️ -
Stephen Colebourne