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>.
I also am not clear - are there public tzdist servers, or is the suggestion that we would have a Python-specific tzdist service and end users would subscribe to it for updates?
I don't know of any free-for-anybody-to-use tzdist servers, though they have been suggested. On the other hand I would expect tzdist servers to be language-agnostic; they would not be Python-specific. In that sense they would be like NTP servers.
I'm mainly asking because I decided early on (on some very good advice) that effectively distributing the data is a big enough task on its own that it would bog down the initial implementation to try and handle both at once
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.