On 2020-02-26 14:31, Paul Eggert wrote:
On 2/25/20 6:40 PM, Paul Ganssle wrote:
My main concern is that my hope is to try to use a time zone data source that can be managed at the system level, independent of language stack. I will admit to never having looked into the details, but I was under the impression that tzdist was something that the system would consume, rather than individual programs, is that wrong?
As a protocol, tzdist can be used both by individual programs and by the system. It's still pretty new and I don't know of any census, but at least Cyrus supports it so that clients can have the latest tzdata even if their OS tzdata is out-of date; see <https://www.cyrusimap.org/imap/download/installation/http/caldav.html>.
Reading that, Cyrus supports converting tz data sources to iCalendar data with vzic which it then makes available via CalDAV for calendar clients; it does not appear to support zoneinfo binary data or TzDist for tzdata clients: "This module is designed to use the IANA Time Zone Database data (a.k.a. Olson Database) converted to the iCalendar format. Cyrus uses a modified vzic to convert IANA formatted data into iCalendar format." and predates TzDist: "recently downloaded time zone data (e.g. “IANA Time Zone Database v.2013h”)" The CMU server no longer appears to be available.
Absolutely. All I'm saying is that the proposal should not preclude having the implementation use tzdist rather than TZif files in the OS. One can use tzdist to distribute TZif data, after all.
Allow your proposal backend to work with local or remote files or tzdist server. -- 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.