Honestly, I would be very worried about doing something like this in the standard library if you're talking about IANA support in particular. It's a very specific type of time zone data which isn't usually present on Windows systems, for example, and which has to have a very flexible release cycle that I doubt would be compatible with Python's release cycle if Python were to try to supply it.
I would say there's two good ways to do something like this (on the format side): 1. Extend the tzinfo API such that there's a version of "tzname()" that represents any kind of canonical "zone string" that doesn't change throughout the year, then allow that to be printed in a formatstr. 2. Offer format string option that inserts str(tzinfo) somewhere, and encourage tzinfo implementations to make str(tzinfo) resolve to some human-readable zone identification. I think in both of these cases it's important to make it clear it's not necessarily the tzid from an IANA string, but just whatever the string representation is, whether that's a GNU-style tz string, an iCal zone spec or whatever. All that said, it also seems a bit unfortunate to deviate from the cross-platform strftime standard. I guess there are already some deviations in the python strftime spec, but that should be at least a minor weight against doing something like this. On the parse side, I think there are a lot of issues. For one thing, the open ended nature of "all potential time zone strings" will probably yield a lot of edge case headaches that will take quite a while to work out (though this may not be too bad as long as multiple open-ended format options are not added). Another problem is that if you have any random string that could be your time zone ID, what kind of tzinfo object is produced by "America/New_York" or something similar? Again we come back to Python favoring IANA and shipping with an IANA zone parser using who knows what data. I'd think the most natural way to implement something like this would be to define an interface for "zone parser" which would take a subset of the string to be parsed and return a tzinfo object, which is passed as an optional parameter to strptime. That way, third parties could provide an implementation that could take a string like "EST5EDT" and produce an appropriate tzinfo object. On November 2, 2016 3:27:18 PM EDT, Alexander Belopolsky <[email protected]> wrote: >On Wed, Nov 2, 2016 at 3:15 PM, Paul G <[email protected]> wrote: > >> Where would the tzid come from? > > >Hmm, I was actually thinking of the time module strftime where %/ can >simply print the value of the TZ environment variable or the system >local >zone setting (which may be tricky to obtain, which is another reason to >do >it in stdlib.) > > >> It's not a standard feature of tzinfo, so wouldn't that involve >changing >> the tzinfo API as well? > > >Yes, to add this to datetime.strftime(), we will need to extend the >tzinfo >API. I have to think some more before making a specific proposal. Any >suggestions? I think this was discussed a few years ago. I'll try to >find >the relevant threads.
pgpglNNVF9Osr.pgp
Description: PGP signature
_______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
