[tz] tzdata source compatibility
murch at fastmail.com
Wed Feb 7 16:31:59 UTC 2018
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.
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
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.
Cyrus Development Team
FastMail US LLC
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4 bytes
Desc: not available
More information about the tz