[tz] Version in zoneinfo files?

[Guy Harris]

On Oct 25, 2015, at 11:17 AM, Paul G <paul at ganssle.io> wrote:

> On 10/25/2015 01:59 PM, Guy Harris wrote:
>> 
>> On Oct 25, 2015, at 10:55 AM, Paul G <paul at ganssle.io> wrote:
>> 
>>> I'm not suggesting that it be impossible to create a weird result when asking for the version, just that there's a standard place for the version to go, and preferably the standard default gives you something that you expected.
>> 
>> I.e., something that works most of the time is sufficient?
>> 
>> So what exactly is the intended use of this version field?
> 
> Maybe I don't fully understand the concerns you are raising, but by way of example, in python-dateutil, we distribute zoneinfo binaries along with the library, and to allow users to query what version of tzdata they are using, we bundle our own metadata file in with zoneinfo (the feature request is here: https://github.com/dateutil/dateutil/issues/27). I gather that this is not uncommon though I'm not an end-user of this particular feature, so I can only speculate as to the various use cases.

And the person who filed that request didn't indicate what their use case was.

I'm not sure I understand the concerns *they* are raising.  What do they intend to *do* with the version string once they get it?  Is this just something to let people know whether they have an up-to-date version of the tzdb files or not?

> Right now, we're expecting a zoneinfo file of our own construction, but there are organizations for whom rebuilding python-dateutil's (and pytz's, and a hundred other zic consumers') zoneinfo database on every tz release is not reasonable, so they would prefer to point dateutil at a shared binary zoneinfo. If each of these zic consumers are expecting their own bespoke way of storing version information, though, they will either return inaccurate information or no information in a case such as this. 
> 
> So, as it is now, it's going to be spotty at best ANYWAY if you do anything other than the completely stock-standard way of handling the databases (unless you maintain your own patched versions of all your zic consumers), so having a way to do it that at least handles the "first order" case (people who deploy zoneinfo files in a standard, but centralized way)

Presumably meaning "deploy standard, unmodified zic output built from a standard tzdb release".

> is a significant improvement over the status quo.