[issue41530] zoneinfo: ZoneInfo raises IsADirectoryError instead of ZoneInfoNotFoundError

Paul Ganssle added the comment: I think that `ZoneInfo('__init__.py')` is also a problem, but a slightly different one. That comes from the fact that in order to support `importlib.resources`, each of the zoneinfo subdirectories needs an `__init__.py`, but the ZoneInfo constructor should

[issue41530] zoneinfo: ZoneInfo raises IsADirectoryError instead of ZoneInfoNotFoundError

Paul Ganssle added the comment: By the way, it might be easiest to start with a PR against backports.zoneinfo, because I have a lot more linting, coverage and format checks set up there: https://github.com/pganssle/zoneinfo -- ___ Python tracker

[issue41025] C implementation of ZoneInfo cannot be subclassed

Paul Ganssle added the comment: New changeset 87d8287865e5c9f137f6b5cf8c34c2c509eb5e9d by Paul Ganssle in branch 'master': bpo-41025: Fix subclassing for zoneinfo.ZoneInfo (GH-20965) https://github.com/python/cpython/commit/87d8287865e5c9f137f6b5cf8c34c2c509eb5e9d

[issue41371] test_zoneinfo fails when lzma module is unavailable

Paul Ganssle added the comment: I think for now skipping the tests when lzma is missing is the easiest thing, though another option would be to drop the compression on the input test data so that the tests don't depend on lzma. Taking a look at the data files, it looks like we get around 50

[issue16995] Add Base32 support for RFC4648 "Extended Hex" alphabet (patch attached)

Paul Ganssle added the comment: Thanks Filipe! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.10 -Python 3.8 ___ Python tracker <https://bugs.python.or

[issue41260] datetime: strftime method takes different keyword argument: fmt (pure) or format (C)

Paul Ganssle added the comment: I think a positional-only argument would be the best option if we could do it, but it would be a backwards-incompatible change and it's probably not worth the hassle. If anyone is using the keyword argument, they're probably using `format=` rather than `fmt

[issue41282] Deprecate and remove distutils

Paul Ganssle added the comment: > So what is the plan to continue to support building cpython itself which > depends on Distutils? Currently the build bootstraps itself without the aid > of an existing Python interpreter instance. There would also be major impacts > across the w

[issue41282] Deprecate and remove distutils

Paul Ganssle added the comment: > I don't think it's a good idea to replace bad habits from distutils with bad > habits in setuptools._distutils. And this is exactly what you get with > pointing directly to setuptools. These are two different questions. We're not asking people t

[issue41282] Deprecate and remove distutils

Paul Ganssle added the comment: Oops, just realized my previous post said `pip install distutils`. I meant to say that `pip install setuptools` will provide the `distutils` module (right now you do `import setuptools; import distutils` and you get the setuptools-provided version; we're

[issue41025] C implementation of ZoneInfo cannot be subclassed

New submission from Paul Ganssle : In the C implementation of zoneinfo.ZoneInfo, __init_subclass__ is not declared as a classmethod, which prevents it from being subclassed. This was not noticed because the tests for ZoneInfo subclasses in C are actually testing zoneinfo.ZoneInfo

[issue41025] C implementation of ZoneInfo cannot be subclassed

Change by Paul Ganssle : -- keywords: +patch pull_requests: +20143 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/20965 ___ Python tracker <https://bugs.python.org/issu

[issue41056] minor NULL pointer and sign issues reported by Coverity

Change by Paul Ganssle : -- nosy: +p-ganssle nosy_count: 3.0 -> 4.0 pull_requests: +20249 pull_request: https://github.com/python/cpython/pull/21083 ___ Python tracker <https://bugs.python.org/issu

[issue41065] Use zip-strict in zoneinfo

Paul Ganssle added the comment: New changeset bc43f6e21244f31d25896875430174cd4ac7604c by Ram Rachum in branch 'master': bpo-41065: Use zip-strict in zoneinfo (GH-21031) https://github.com/python/cpython/commit/bc43f6e21244f31d25896875430174cd4ac7604c

[issue41056] minor NULL pointer and sign issues reported by Coverity

Paul Ganssle added the comment: New changeset 6c56356109616ea1292aafa48d30536279ec0937 by Paul Ganssle in branch '3.9': [3.9] bpo-41056: Fix a possible MemoryError leak within zoneinfo. (GH-21007) https://github.com/python/cpython/commit/6c56356109616ea1292aafa48d30536279ec0937

[issue41118] datetime object does not preserve POSIX timestamp

Paul Ganssle added the comment: There's a pretty clear warning on the documentation that utcfromtimestamp is unsuitable for this purpose: https://docs.python.org/3/library/datetime.html#datetime.datetime.utcfromtimestamp What you want is a datetime that knows what time zone it's in, so

[issue41059] Large number of Coverity reports for parser.c

Change by Paul Ganssle : -- nosy: +pablogsal ___ Python tracker <https://bugs.python.org/issue41059> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40799] Create Lib/_pydatetime.py file to optimize "import datetime" when _datetime is available

Paul Ganssle added the comment: As for deciding between moving to `datetime/` and moving to `_pydatetime`, I think we should send an e-mail to Python-Dev about it to get a wider perspective, because the import machinery is a lot of black magic, and I know that there are large proprietary

[issue40799] Create Lib/_pydatetime.py file to optimize "import datetime" when _datetime is available

Paul Ganssle added the comment: > bout _strptime, I see that the time.strptime() imports internally the > _strptime module. Ah, sorry, my remark about including `_strptime` was off the cuff — I thought it was only used in `datetime`, which is why I said "possibly _strptime"

[issue40931] zoneinfo gives incorrect dst() in Europe/Madrid in 1938

New submission from Paul Ganssle : Apparently in 1938, Madrid had a "double daylight saving time", where they transitioned from WET (+0) → WEST (+1) → WEMT (+2) → WEST (+1) → WET (+0): $ zdump -V -c 1938,1940 'Europe/Madrid' Europe/Madrid Sat Apr 2 22:59:59 1938 UT = Sat Apr 2 22:

[issue40933] zoneinfo may give incorrect dst() in Europe/Minsk in 1942

New submission from Paul Ganssle : Related to bpo-40930 and bpo-40931, it *seems* that in 1942 only, `zoneinfo.ZoneInfo` returns -01:00 for DST in Europe/Minsk: >>> from datetime import datetime, timedelta >>> from backports.zoneinfo import ZoneInfo >>>

[issue40686] Compiler warnings in _zoneinfo.c on Windows build in 64-bit

Change by Paul Ganssle : -- pull_requests: +19849 pull_request: https://github.com/python/cpython/pull/20624 ___ Python tracker <https://bugs.python.org/issue40

[issue40908] datetime strftime with %Y and 2 digit years

Paul Ganssle added the comment: This is a duplicate of bpo-13305 and is due to platform-specific implementations of %Y. On Linux, `strftime()` does not zero-pad to 4, and if you need to represent years <1000, you should use "%4Y" to zero-pad the output. I think the ideal res

[issue40930] zoneinfo gives incorrect dst() in Pacific/Rarotonga between 1978 and 1991

New submission from Paul Ganssle : While developing a shim for deprecating pytz, I discovered this issue with the Pacific/Rarotonga zone: >>> from datetime import datetime, timedelta >>> from backports.zoneinfo import ZoneInfo >&

[issue41321] Calculate timestamp is wrong in datetime.datetime

Paul Ganssle added the comment: Hi dh4931 — this is the expected result, assuming that the offsets changed between those two dates in your system local time. The .timestamp() method returns an epoch time, which is the number of seconds since 1970-01-01T00:00:00 UTC, and so it is inherently

[issue41254] Add to/from string methods to datetime.timedelta

Paul Ganssle added the comment: I think it is unlikely that we'll want to experiment with this directly in CPython. I don't think a fixed format (other than the annoying one that you already get from calling `str` on a timedelta) is appropriate, but designing a modular format for time

[issue41025] C implementation of ZoneInfo cannot be subclassed

Paul Ganssle added the comment: New changeset 33d3c64095bcdf9066a3441f6dda5d2e2f4118a8 by Miss Islington (bot) in branch '3.9': bpo-41025: Fix subclassing for zoneinfo.ZoneInfo (GH-20965) (GH-21876) https://github.com/python/cpython/commit/33d3c64095bcdf9066a3441f6dda5d2e2f4118a8

[issue42874] running configure on Solaris 10 gives grep "illegal option" errors

Change by Paul Ganssle : -- keywords: +patch pull_requests: +23025 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24200 ___ Python tracker <https://bugs.python.org/issu

[issue42874] running configure on Solaris 10 gives grep "illegal option" errors

Paul Ganssle added the comment: This particular grep statement is used to validate the `tzpath` variable. Apparently it is easy enough to achieve what I was going for using vanilla grep with no options, so I've created GH-24200 to fix the issue. I notice that there are other uses of `-q

[issue21041] pathlib.PurePath.parents rejects negative indexes

Paul Ganssle added the comment: I think you may have confused my thoughts as to why this might be considered ambiguous with an actual suggestion for what the semantics should be. I think that we should stick with `p.parents[x] == tuple(p.parents)[x]` for any valid value of `x`, which means

[issue42444] pathlib.PurePath properties annotated with .. data directive

New submission from Paul Ganssle : Currently, it seems that the pathlib module uses `.. data::` to annotate the properties of the PurePath type (e.g. .parts, .drive, .root, etc). See: https://github.com/python/cpython/blob/ff420f0e08a2443339da0df7ace95e14177bac53/Doc/library/pathlib.rst

[issue21041] pathlib.PurePath.parents rejects negative indexes

Paul Ganssle added the comment: New changeset 79d2e62c008446fbbc6f264bb8a30e2d38b6ff58 by Yaroslav Pankovych in branch 'master': Added support for negative indexes to PurePath.parents (GH-21799) https://github.com/python/cpython/commit/79d2e62c008446fbbc6f264bb8a30e2d38b6ff58

[issue35498] Parents objects in pathlib.Path don't support slices as __getitem__ arguments

Paul Ganssle added the comment: New changeset 79d2e62c008446fbbc6f264bb8a30e2d38b6ff58 by Yaroslav Pankovych in branch 'master': Added support for negative indexes to PurePath.parents (GH-21799) https://github.com/python/cpython/commit/79d2e62c008446fbbc6f264bb8a30e2d38b6ff58

[issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable in calenderrule_new

Paul Ganssle added the comment: There are at least two issues with this: 1. This is a constructor for a struct, and the struct would really unnecessarily balloon in size if we switched everything over to be 32-bit integers (which I think is your suggestion?). This is not a major concern

[issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable in calenderrule_new

Paul Ganssle added the comment: > Just my two cents, this isn't just "some compilers". Everything from gcc, > msvc, C# to the rust compiler complain about this sort of code. As they > should, this is effectively dead code. They complain because most of the time it's a si

[issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable in calenderrule_new

New submission from Paul Ganssle : This is a code style issue — in https://github.com/python/cpython/pull/23614, a regression was deliberately introduced to satisfy an overzealous compiler. The `day` variable has logical bounds `0 <= day <= 6`. In the original code, both

[issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable in calenderrule_new

Paul Ganssle added the comment: As I mentioned, it's a style issue. Yes this did not introduce any user-observable bugs, nor should it have changed the machine code emitted by the assembly on any competent compiler. The issue is that I had deliberately chosen to do a "redundant&q

[issue42663] zoneinfo does not support full range of allowed transition hours in fallback string

New submission from Paul Ganssle : TZif files consist of a list of transitions followed by a POSIX TZ var-style string of a form like "AAA3BBB,M3.2.0/01:30,M11.1.0/02:15:45", which decodes to "AAA (UTC-3) is the standard time and BBB (UTC-2) is the DST time, DST applies start

[issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable in calenderrule_new

Paul Ganssle added the comment: > Adding a static assertion about the signedness of uint8_t looks meaningless > to me. My proposal is to add a static assertion that `day` is an unsigned type. In the code it would look something like it does in the backports.zoneinfo code

[issue42697] 3.8.7rc1 regression: 'free(): invalid pointer' after running backports-zoneinfo test suite

Paul Ganssle added the comment: For future reference, this bug is triggered only when `.fromutc` is called on a subclass of `datetime` and the resulting date is the second ambiguous time (e.g. if there's a DST transition from 02:00 → 01:00, and the result of the `.fromutc` call

[issue42371] datetime.fromisoformat(): Omitted colon in timezone suffix raises ValueError

Paul Ganssle added the comment: This is the expected behavior of `.fromisoformat()`. A similar issue is https://bugs.python.org/issue35829, which asks for the "Z" suffix to be supported. There is a note about this in the documentation: https://docs.python.org/3/library/dat

[issue21041] pathlib.PurePath.parents rejects negative indexes

Paul Ganssle added the comment: I am not seeing any compelling reasons to avoid supporting negative indexes *or* slices here. If I had to guess about the confusing semantics of negative indices, I would guess it's the fact that the index in the -1 position for a non-empty Path will always

[issue35498] Parents objects in pathlib.Path don't support slices as __getitem__ arguments

Paul Ganssle added the comment: One question I would have about this is that `.parents` is a lazily-calculated sequence, not a list or a tuple, so it's not immediately obvious what the return type of a slice would be. I don't think it makes sense to return, e.g. a `_PathParents` object

[issue35498] Parents objects in pathlib.Path don't support slices as __getitem__ arguments

Paul Ganssle added the comment: New changeset 452058448335b39c784af9a047f9c4a1767c0b00 by Joshua Cannon in branch 'master': bpo-35498: Added slice support to PathLib parents attribute. (GH-11165) https://github.com/python/cpython/commit/452058448335b39c784af9a047f9c4a1767c0b00

[issue35498] Parents objects in pathlib.Path don't support slices as __getitem__ arguments

Change by Paul Ganssle : -- dependencies: -pathlib.PurePath.parents rejects negative indexes resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue42390] Other Python implementations may not expose the module name in datetime type names

Paul Ganssle added the comment: Is this an actual problem for another implementation of Python? Is there some reason to think that we intended the repr of a `datetime` object to be implementation-defined? -- nosy: +p-ganssle ___ Python tracker

[issue42094] isoformat() / fromisoformat() for datetime.timedelta

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue42094> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42094] isoformat() / fromisoformat() for datetime.timedelta

Paul Ganssle added the comment: This is probably more feasible than the proposal in bpo-41254 since it's a well-defined spec (mostly — it includes an optional alternative format and the number of digits allowed is defined "by agreement", thus defeating the purpose of us

[issue42390] Other Python implementations may not expose the module name in datetime type names

Paul Ganssle added the comment: What is an example of another Python implementation that has this property? Is there a concrete issue open somewhere that this is solving? I am not unsympathetic to the idea of accommodating other implementations of Python, but this is very abstract and I

[issue24929] _strptime.TimeRE should not enforce range in regex

Paul Ganssle added the comment: I also commented on GH-26215 ( https://github.com/python/cpython/pull/26215 ), but for posterity, I'll note a few things: 1. It seems that (and this may have changed since 2015), `_strptime._strptime` now has a stage that (unconditionally?) constructs

[issue42109] Use hypothesis for testing the standard library, falling back to stubs

Paul Ganssle added the comment: @Terry > The problem with random input tests in not that they are 'flakey', but that > they are useless unless someone is going to pay attention to failures and try > to find the cause. This touches on the difference between regression testing

[issue42109] Use hypothesis for testing the standard library, falling back to stubs

Paul Ganssle added the comment: > I use hypothesis during development, but don't have a need for in the the > standard library. By the time code lands there, we normally have a specific > idea of what edge cases needs to be in the tests. The suggestion I've made here is that we use

[issue44307] date.today() is 2x slower than datetime.now().date()

Paul Ganssle added the comment: Yeah, I knew this was slower and it's been on my long list to look at it (tied to this is the fact that `datetime.today()` is basically just a slow version of `datetime.now()`, in defiance of user expectations). My inclination is that we shouldn't re

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

Paul Ganssle added the comment: I'm +1 for Pablo's approach. That's approximately what I meant by "special-case it in the REPL layer" anyway. Are there any downsides to doing it this way? It seems tightly scoped and with minima

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

Paul Ganssle added the comment: If we want to confine the behavior to just the repl, we could possibly have the repl set an environment variable or something of that nature for interactive sessions, so that `__repr__` of `exit` can tell the difference between being invoked in a REPL

[issue42109] Use hypothesis for testing the standard library, falling back to stubs

Paul Ganssle added the comment: I do not want to dissuade you from figuring out how minithesis / hypothesis works (far from it), but I'm wondering if the question of how shrinking works is germane to the issue at hand, which is whether or not hypothesis / property-based-testing is suitable

[issue43295] datetime.strptime emits IndexError on parsing 'z' as %z

Paul Ganssle added the comment: New changeset c87b81dcb2c22b6d151da39a0f65d5db304f59a8 by Miss Islington (bot) in branch '3.9': bpo-43295: Fix error handling of datetime.strptime format string '%z' (GH-24627) (#25695) https://github.com/python/cpython/commit

[issue43132] Incorrect handling of PyObject_RichCompareBool() in the _zoneinfo module

Paul Ganssle added the comment: Re-opening because this was merged without tests. @ZackerySpytz would you mind adding tests to hit these error cases? I've spent some time satisfying myself that it's indeed possible, and I've detailed a general outline here: https://github.com/python

[issue43484] valid datetimes can become invalid if the timezone is changed

Paul Ganssle added the comment: > That it allows creating the datetime instance looks like a bug to me, i.e. a > time before 0001-01-01 00:00 UTC is invalid. What am I misunderstanding? `datetime.datetime(1, 1, 1, tzinfo=timezone(timedelta(hours=1)))` is a valid datetime, it'

[issue43382] github CI blocked by the Ubuntu CI with an SSL error

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue43382> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43354] xmlrpc.client: Fault.faultCode erroneously documented to be a string, should be int

Paul Ganssle added the comment: The evidence you have here seems pretty compelling and this change seems straightforward enough. I don't see an expert listed here, but I'm happy to merge a docs PR fixing this. Probably a good idea to make a PR to typeshed in parallel, in case they have

[issue15443] datetime module has no support for nanoseconds

Paul Ganssle added the comment: > I don't think full nanosecond support is feasible to complete in the > remaining weeks This may be so, but I think the important part of that question is "what work needs to be done and what questions need to be answered?" If the answer

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

Paul Ganssle added the comment: At this point I think we should probably start a thread on python-dev to see how people feel about it. I'd be happy to author or co-author a PEP for this if need be. -- ___ Python tracker <https://bugs.python.

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

Paul Ganssle added the comment: > In fact, you're proposing to use exit as a keyword, but lying about it to the > users. If it were really so important, then it _should_ be a keyword, and at > least I'd know that I can't use it for my variables anymore. (It's not the >

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

Paul Ganssle added the comment: Re-opening this because I think the discussion is not done and I don't see any reason why this was rejected. > Related 2005 python-dev discussion: > https://mail.python.org/archives/list/python-...@python.org/thread/VNGY2DLML4QJUXE73JLVBIH5WFBZNIKG/

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

Change by Paul Ganssle : -- stage: resolved -> ___ Python tracker <https://bugs.python.org/issue44603> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue44829] zoneinfo.ZoneInfo does not check for Windows device names

Paul Ganssle added the comment: Sorry you didn't receive a response to your security@ email, I guess my response just went to the PSRT, not to you as well. I believe we determined that this was an issue in importlib.resources generally, not specific to zoneinfo. I think

[issue44831] Inconsistency between datetime.now() and datetime.fromtimestamp(time.time(), None)

Paul Ganssle added the comment: I think this is a rounding issue. `time.time()` returns an epoch timestamp as a float and at the current epoch time, floats are spaced ~500ns apart. `datetime.datetime.now` does a floor division when rounding: https://github.com/python/cpython/blob

[issue45515] Add reference to zoneinfo in the datetime module documetnation

New submission from Paul Ganssle : Right now the datetime documentation recommends using `dateutil.tz` for IANA time zones, but we should update this to point to `zoneinfo`. -- assignee: p-ganssle components: Documentation messages: 404207 nosy: p-ganssle priority: low severity

[issue45515] Add reference to zoneinfo in the datetime module documetnation

Change by Paul Ganssle : -- keywords: +patch pull_requests: +27309 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29038 ___ Python tracker <https://bugs.python.org/issu

[issue45414] pathlib.Path.parents negative indexing is wrong for absolute paths

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue45414> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45414] pathlib.Path.parents negative indexing is wrong for absolute paths

Paul Ganssle added the comment: This is a great bug report, but for anyone else who gets a bit lost in the details, here's the core of the issue: >>> p = Path("/1/2") >>> q = Path("1/2") >>> p.parents[-1] # This is correct PosixPath('/') >

[issue46124] Deprecation warning in zoneinfo module

Paul Ganssle added the comment: Jason's patch looks good to me, but I don't understand why Karthikeyan originally suggested using `normalize_path`. Trying to dig through exactly how `files().joinpath().open` is implemented has so many layers of indirection and abstract classes that I can't

[issue41260] datetime, date and time: strftime method takes different keyword argument: fmt (pure) or format (C)

Paul Ganssle added the comment: Updating this issue to cover the problem in date, time and datetime. -- title: datetime: strftime method takes different keyword argument: fmt (pure) or format (C) -> datetime, date and time: strftime method takes different keyword argument: fmt (p

[issue45814] datetime.time.strftime: use the same function signature for C and Python implementations

Paul Ganssle added the comment: I think this is mostly a duplicate of bpo-41260, which has an open PR on it. I think that got lost in the shuffle, I'm sad we didn't fix it in Python 3.10. I think we should migrate all of these signatures that differ to whichever one the C implementation

[issue46319] datetime.utcnow() should return a timezone aware datetime

Paul Ganssle added the comment: Yes, this is the documented behavior, including a warning against using UTC now in the documentation! There is some possibility of removing utcnow entirely as an "attractive nuisance", but I suspect that this will lead to much consternation and han

[issue12756] datetime.datetime.utcnow should return a UTC timestamp

Paul Ganssle added the comment: > from practical experience, it is a whole lot better to not deal with > timezones in data processing code at all, but instead only use naive UTC > datetime values everywhere, expect when you have to prepare reports or output > which has a require

[issue46614] Add option to output UTC datetimes as "Z" in `.isoformat()`

Paul Ganssle added the comment: I think this approach is probably the best we can do, but I could also imagine that users might find it to be confusing behavior. I wonder if there's any informal user testing we can do? I guess the ISO 8601 spec does call "Z" the "UTC

[issue47207] Switch datetime docstrings / documentation to using "Returns" rather than "Return"?

New submission from Paul Ganssle : In bpo-9305, Fred Drake recommends preferring `Returns ...` over the imperative `Return ...`: https://bugs.python.org/issue9305#msg110912 Currently we're pretty consistent about `Return ...`, which is consistent with PEP 257: https://peps.python.org/pep

[issue47228] Document that naïve datetime objects represent local time

New submission from Paul Ganssle : Currently, the `datetime` documentation has this to say about naïve datetimes: > A naive object does not contain enough information to unambiguously locate > itself relative to other date/time objects. Whether a naive object represents > Co

[issue46614] Add option to output UTC datetimes as "Z" in `.isoformat()`

New submission from Paul Ganssle : As part of bpo-35829, it was suggested that we add the ability to output the "Z" suffix in `isoformat()`, so that `fromisoformat()` can both be the exact functional inverse of `isoformat()` and parse datetimes with "Z" outputs.

[issue35829] datetime: parse "Z" timezone suffix in fromisoformat()

Paul Ganssle added the comment: I don't think it's necessary to add a feature to `isoformat()` just for the purpose of being able to add the corresponding parser, particularly when the plan is to implement a much broader ISO 8601 parser for Python 3.11 (I've done most of the implementation

[issue46447] datetime.isoformat() documentation does not point to the risk of using it with naive datetime objects

Paul Ganssle added the comment: Sorry I missed this! Thank you for taking the time to write this up and to make a PR. Unfortunately, I don't think I agree with the idea of warning about this. The warnings about `utcnow` and `utcfromtimestamp` are a problem because `utcnow

<    1   2   3   4   5