[tz] timezone DB distribution

[Michael Douglass]

On 9/8/20 01:18, Brian Inglis wrote:
> 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,

Not true. Bedework can exist as a completely separate module - in fact 
is built with that assumption. While other may be built as part of a 
larger project they can still handle tzdist queries as laid out in the 
standard.

The bedework tzdist server can run as a primary server delivering data 
from files or as a secondary server updating from another tzdist server.

Bedework calendar server uses no internal requests to fetch timezones, 
it uses tzdist so it could fetch from some other remote server if one 
were available.

>   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.
Expectations differ.
>
> 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.

Blind replacements are what we have currently. If an application is 
using OS or runtime system timezones they can change without notice at 
any time - whenever somebody decides to patch the underlying system.

As a calendar implementer, deployer and maintainer I understand those 
specific problems. In fact to the organizer the event often looks 
unchanged - what might have changed is the UTC time that is equivalent 
to the local time. It's still the same event - has the same UID. And yes 
- we should reschedule to give all parties an opportunity to re-evaluate

Tzdist was designed to allow consumers to determine what timezones had 
changed since they last asked. For a calendar system that at least 
allows us to limit our search of possibly impacted data. It would be 
nice if we had information on what changed and we can possibly derive 
that but that can be a later addition.

But possible consumers of tzdist go beyond large scale calendar systems. 
When we started discussions about tzdist many years ago the phone 
vendors of the time were very enthusiastic. They could only store a few 
timezones and would like a standardized service that allowed them to 
fetch individual timezones. While phones have got more powerful I'm 
guessing that small devices are in the same position. They don't care 
much what changed but they do need to know that the timezone they use 
has changed.

I quite understand that tzdist only solves part of the problem but it's 
a pretty widespread part and dealing with that in a standardized manner 
seems liek a good start.