[Datetime-SIG] Matching +-HH:MM in strptime

Sat Oct 21 02:34:53 EDT 2017

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 <paul at ganssle.io> 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 <paul at ganssle.io> 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
> >> Datetime-SIG at python.org
> >> 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
> > Datetime-SIG at python.org
> > 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
> Datetime-SIG at python.org
> https://mail.python.org/mailman/listinfo/datetime-sig
> The PSF Code of Conduct applies to this mailing list:
> https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20171021/ab50afee/attachment.html>