[tz] tzdata source compatibility

[Ken Murchison]

On 02/07/2018 07:35 AM, Stephen Colebourne wrote:
> On 6 February 2018 at 16:37, Christos Zoulas <christos at zoulas.com> wrote:
>> On Feb 6,  4:51pm, mark at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: murch.vcf
Type: text/x-vcard
Size: 4 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/tz/attachments/20180207/ac56528f/attachment.vcf>