On 2/25/20 1:38 PM, Paul Ganssle wrote:
I sent out the proposal today, discussion is happening on the Python discourse: https://discuss.python.org/t/3468
A few comments, which you're welcome to pass on to that forum: * Having global state can lead to problems (even in single-threaded apps), and this proposal has global state in the implementation of the 'set_tzpath' function. Instead of that function, how about an optional argument to the ZoneInfo constructors? The optional argument would specify the path for apps that don't want the default path. Then apps wouldn't need set_tzpath. * The proposal is silent on the issue of what happens during updates to tzdata files while a Python program is running. Should this update be reflected immediately in all Python-level calls? Should it wait until the next call to ZoneInfo on the affected zone, which means that zones are not immutable? Should the update be ignored and the program proceed as if the update hasn't happened? Or are all these valid implementations of the spec? Whichever you decide, the decision should be written down so that developers are put on notice. * How do I get tzdata-based leap second support, if I want it? Or are leap seconds specifically out of scope? * You might want to mention TZDIST (RFC 7808) as an alternative source for tzdata that a Python implementation could use instead of TZif files in a local filesystem.