[tz] timezone DB distribution
Brian.Inglis at SystematicSw.ab.ca
Tue Sep 8 05:18:33 UTC 2020
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
>>>> 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 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.]
More information about the tz