On 9/7/20 11:06 PM, Michael Douglass wrote:
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.
The tzdist module in Cyrus should be completely up to date with RFC 7808 and will return RFC 8536-compliant TZif data when requested. It can also spit out zdump formatted data, which I used for debugging. Making this a stand-alone service would take a lot of work since it uses the built-in httpd server and shares a lot of I/O handling APIs with imapd, etc. -- Kenneth Murchison Senior Software Developer Fastmail US LLC