ok, let's try to separate the issues and choices on each one: 1. Extending strptime to support time zone offset with : separator: Should a single directive accepts either hhmm or by:mm or use two separate directives?
2. Round tripping of isoformat() back to datetime value: Implement custom isoparse() function or extend strptime so isoparse simply calls strptime with a default format? Support all variations produced by isoformat or just a subset? (Variations include with/without fraction, with/without tz and separator choice) I suggest 1 separate directives 2a extend strptime and 2b support all variations. Do you have different preferences on any of these questions? I understand that the number of extensions to support this seems excessive to you. Technically, my proposed "%.f" is not really necessary. I added it for completeness. We can keep using ".%f" for non-optional fraction and define "%?f" to implicitly include the dot. The distinction between "%z", "%:z" and "%?:z"" can also be narrowed down. This can be done, for example, by making "%z" and "%?s" always accept hhmm with or without the : separator. On Fri, 20 Oct 2017 at 17:16, Paul G <[email protected]> wrote: > I think this would be a much bigger change to the strptime interface than > is actually warranted, and probably would add in additional, unnecessary > complexity by introducing the concept of optional matches. Adding the > capability to match HH:MM offsets is a reasonable extension partially > because that is a standard representation that is currently *not* covered > by strptime, and the fact that that's how isoformat() represents the offset > just makes this lack all the more acute. > > I think it should be uncontroversial to add *one* of these two %z > extensions to Python 3 without getting bogged down in allowing a single > strptime string to match any output from `.isoformat`. > > That said, I'm also very much in favor of a `.isoparse` or > `.fromisoformat` constructor that *is* the inverse of `isoformat`, which > should solve the issue without sweeping changes to how `strptime` works. > > On 10/19/2017 04:07 PM, Oren Tirosh wrote: > > https://github.com/orent/cpython/tree/strptime_extensions > > > > %:z - matches +HH:MM > > %?:z - optional %:z > > %.f - equivalent to .%f > > %?.f - optional %.f > > %?t - matches ' ' or 'T' > > > > What they all have in common is that together they make it possible to > > write a strptime format that matches all possible output variations of > > datetime.__str__/ datetime.isoformat. > > > > The time zone not only supports the : separator but also allows making > the > > entire component optional, as isoformat() will add it only for aware > > datetime objects. The seconds fraction is dropped from the default string > > representation if the datetime represents a whole second. Since it is > > dropped along with the decimal dot, I first made "%.f" that includes the > > dot and then created the optional variant. Finally, "%?t" can be used to > > accept a timestamp with either of the separators defined in iso8601. > > > > It is quite absurd that datetime cannot parse its own string > > representation. Using these extensions an .isoparse() method may be added > > that calls strptime('%Y-%m-%d%?t%H:%M:%S%?.f%?:z') and supports full > > round-tripping of all possible datetime values that do not not use a > custom > > tzinfo. > > > > Oren > > > > > > > > On Thu, 19 Oct 2017 at 17:06, Paul G <[email protected]> wrote: > >> > >> There is a new issue about the %z directive in strptime on the issue > > tracker: https://bugs.python.org/issue31800 (linked to a few related > > issues), and a linked PR expanding the definition of %z to match HH:MM: > > https://github.com/python/cpython/pull/4015 > >> > >> I think either adding a %:z directive or expanding the definition of %z > > would be pretty important, and I think there's a good case to be made for > > either one. To summarize the arguments for people on the mailing list: > >> > >> The argument for expanding the definition of %z that I find strongest is > > that according to the linux man pages ( > > http://man7.org/linux/man-pages/man3/strptime.3.html ), while %z > generates > > +-HHMM in strftime, strptime is supposed to match "An RFC-822/ISO 8601 > > standard timezone specification",and ISO 8601 uses +-HH:MM, so if we're > > following those linux pages, we should be accepting the version with the > > colon. > >> > >> The argument that I find most compelling for adding a %:z directive are: > >> > >> 1. maintains the symmetry between strftime and strptime > >> 2. allows users to be stricter about their datetime format > >> 3. has precedent in that GNU's `date` command accepts %z, %:z and > > %::z formats > >> > >> Can we establish some consensus on which should be done so that it can > be > > implemented? > >> > >> Best, > >> > >> Paul > >> > >> _______________________________________________ > >> 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/ > > > > > > > > _______________________________________________ > > 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/ > > > > _______________________________________________ > 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/ >
_______________________________________________ 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/
