[tz] timezone DB distribution
mikeadouglass at gmail.com
Tue Sep 8 03:06:20 UTC 2020
On 9/7/20 19:43, Tim Parenti wrote:
> A reasonable criterion for inclusion should probably be whether the
> service makes the protocol accessible for arbitrary consumption,
> whether openly or by authenticated subscription.
> The phrase "supports TZDIST" can of course mean several
> different things, but while there are benefits to using the protocol
> internally to a product, I don't think this fulfills the expectation
> that it would tend to evoke here. From the perspective of someone
> reading tz-link.html, it's much more important to answer "where are
> some public tzdist servers I can point my project to?" rather than
> "what's something that happens to speak tzdist to its own clients?"
> (The latter, frankly, is of little relevance to consumers of the tz
> project data.)
We implemented (and use) those servers to provide a starting point.
Having a service requires some infrastructure maintained by some body or
consortium. I believe Ken's server fully supports tzdist (and beyond).
Mine may be a little out of date but supports pretty much the latest.
However, neither of us can provide the infrastructure - that's for
somebody such as IANA
> Tim Parenti
> On Mon, 7 Sep 2020 at 17:24, Paul Eggert <eggert at cs.ucla.edu
> <mailto:eggert at cs.ucla.edu>> wrote:
> On 9/7/20 1:23 PM, Brian Inglis wrote:
> > If you follow those links and dig into those servers, they
> appear to be mail
> > server calendar addins, which use vzic to convert tzdata source
> into VTIMEZONEs,
> > for updating and caching calendar zones, not providing any kind
> of service or
> > distribution, except to their own mail server calendar clients.
> Thanks for following those links, which I didn't bother to do. If
> they don't
> support the TZDIST protocol then I suppose I should revert the
> change to tz-links.html which says they do.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tz