On Sat, 21 Oct 2017 at 16:08, Mario Corchero <mariocj89@gmail.com> wrote:

Sorry, hit send by mistake on the previous message.

That is fine for parsing, but my issue with this is symmetry with strftime.

I can agree with having a %:z for support in strftime but I think that is a separate change. The issue I opened with the attached PR focused only in strptime to facilitate the discussion.

Yes, strftime is a separate issue, but still relevant as a design concern for any new changes to strptime.

My revised proposal is this:

Add "%:z" with the following semantics:

1. Requires ":" separator

2. Officially matches the empty string, producing a naive datetime (tzinfo=None)

3. [maybe] officially matches "Z", equivalent to "+00:00"

For "%z", retain the existing semantics, with one extension

1. Does not require ":" (but silently accepts it)

2. Does not match the empty string

Here's why:

[snip] Oren:

You can say that the real source of the asymmetry here is not with my proposal but rather in the underlying strftime/strptime: on formatting, %z yields an empty string for a naive timestamp rather that producing an error. But on parsing, it refuses to parse a timestamp with no offset. A truly symmetric implementation would have accepted it as a naive timestamp.

Too late for %z because it must remain backward compatible, but perhaps %:z can be made to accept a missing offset as a naive timestamp. The user can then check for naive timestamp and reject them if they are unacceptable in that context, rather than specifying whether a missing timestamp is acceptable or not in the format string. I have no problem with either solution

[snip]

A separate proposal:

Add "%.f" with the following semantics:

1. Offially matches empty string, producing a timestamp with 0 fraction.

2. Otherwise equivalent to ".%f"

Retracting proposal for "%?t" for now.

With these two extensions, an strptime format can be written that can parse and losslessly round-trip the output of datetime.__str__, or isoformat() with the default space separator for all possible datetime values, naive or aware, except those using custom tzinfo.

While not part of the proposal, these two extensions may also be naturally applied to strftime so that the same format string used for parsing will also produce an output identical to isoformat(), including naive timestamps and whole second timestamps.