On 2020-09-07 20:59, Michael Douglass wrote:
On 9/7/20 22:56, Michael Douglass wrote:
On 9/7/20 17:24, Paul Eggert 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 recently-proposed change to tz-links.html[1] which says they do.
No - neither bedwork nor Darwin have any mail element - they are calendar and contacts servers. Both bedework (which I'm responsible for) and Cyrus (for which Ken is responsible) support TZdist.
There is code in both to convert tzdata source - mine is partially working - Ken's is in much better shape.
The reason VTIMEZONE was the only supported data format is it was the only one defined at the time. That's why Ken started the TZif definition so that TZDIST could deliver the data used by OSs for example.
TZDIST is not data format specific. It's just that at this stage there aren't may defined formats.
I can't speak for Cyrus but the tzdist server in bedework is a separate project in github. I can add a direct link
And I just realized it is already a direct link.
But those implementations do not obviously appear to be able to run as standalone services, only as modules within their host mail/calendar server, responding to internal requests, not any documented external interface, and only support current timezones, as would running vzic statically against tzdata sources to produce files, not any history or delta updates e.g. show me what changed in zone a/b since version 2019c, nor respond to other servers to provide global updates, which would be the expectation of anyone on this list wanting to access or run what we would expect from a tzdist server. Blind replacement of a previous version with the current version does not really help anyone understand what changes in their schedule, other than the previous event disappears to be replaced by a new event with some common attributes, and requires all events be re-interpreted against whatever is updated or currently stored for that time zone data, whenever any process wants to determine which events are pending for some future period. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.]