[issue15390] PEP 3121, 384 refactoring applied to datetime module

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

[issue33071] Document that PyPI no longer requires 'register'

New submission from Paul Ganssle <p.gans...@gmail.com>: I've been asked to post this by @brainwave (who is having some trouble getting an account on bpo due to technical difficulties). Per twine's github issue 311 ( https://github.com/pypa/twine/issues/311 ), it seems that distutil'

[issue33069] Maintainer information discarded when writing PKG-INFO

New submission from Paul Ganssle <p.gans...@gmail.com>: This is basically the same as issue 962772, as there seems to have been a regression. The current version of distutils discards author= metadata if maintainer= is present, even though PEP 345 has added the Maintainer: and Main

[issue33069] Maintainer information discarded when writing PKG-INFO

Change by Paul Ganssle <p.gans...@gmail.com>: -- keywords: +patch pull_requests: +5869 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue33069] Maintainer information discarded when writing PKG-INFO

Paul Ganssle <p.gans...@gmail.com> added the comment: One thing that's unclear to me is whether PKG-INFO metadata spec should be considered exhaustive or whether you can add additional fields and still be considered compliant with the spec. If the latter is true, I think there's some

[issue33069] Maintainer information discarded when writing PKG-INFO

Paul Ganssle <p.gans...@gmail.com> added the comment: @ncoghlan Yes, setuptools is affected. I've reported it there as well: https://github.com/pypa/setuptools/issues/1288 I have patches for both distutils and setuptools prepared. The distutils patch is more controversial b

[issue28602] `tzinfo.fromutc()` fails when used for a fold-aware tzinfo implementation

Change by Paul Ganssle <p.gans...@gmail.com>: -- versions: +Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28602> ___

[issue33069] Maintainer information discarded when writing PKG-INFO

Paul Ganssle <p.gans...@gmail.com> added the comment: I've fixed this in setuptools ( PR here: https://github.com/pypa/setuptools/pull/1294 ). Should we leave this open to track distutils upgrading to support all of PEP 345, or close this with "distutils will never su

[issue33069] Maintainer information discarded when writing PKG-INFO

Paul Ganssle <p.gans...@gmail.com> added the comment: > Donald made an interesting suggestion over on > https://github.com/pypa/packaging-problems/issues/127#issuecomment-374401331, > which was to have distutils stop overwriting the Author metadata with the > Maintainer

[issue32988] datetime.datetime.strftime('%s') always uses local timezone, even with aware datetimes

Paul Ganssle <p.gans...@gmail.com> added the comment: adamwill: I think datetime's strftime is a wrapper around the system strftime, so it varies between platforms. Might be useful to specify which platform you are seeing this behavior on. -- nosy: +p-g

[issue32988] datetime.datetime.strftime('%s') always uses local timezone, even with aware datetimes

Paul Ganssle <p.gans...@gmail.com> added the comment: I suspect discussion should be centralized in issue 12750, but if it were up to me %s would either work as expected or throw an error. Silently giving the wrong answer is a terrible comp

[issue32988] datetime.datetime.strftime('%s') always uses local timezone, even with aware datetimes

Paul Ganssle <p.gans...@gmail.com> added the comment: It seems that %s is not supported and the fact that it works at all is incidental. See issue 12750 and this SO thread: https://stackoverflow.com/questions/11743019/convert-python-datetime-to-epoch-with-st

[issue34903] strptime %d handling of single digit day of month

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

[issue35004] Odd behavior when using datetime.timedelta under cProfile

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

[issue19376] document that strptime() does not support the Feb 29 if the format does not contain the year

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

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

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

[issue19376] document that strptime() does not support the Feb 29 if the format does not contain the year

Paul Ganssle added the comment: @Victor: You mean a PR to fix the *issue* or a PR to add this to the docs? The current behavior is pretty counter-intuitive, particularly because it also fails because of the (relatively) little-known fact that 1900 happens to not be a leap year because

[issue35145] sqlite3: "select *" should autoconvert datetime fields

Paul Ganssle added the comment: According to the sqlite documentation, there's no fundamental datetime type in sqlite: https://www.sqlite.org/datatype3.html#date_and_time_datatype SQLite does not have a storage class set aside for storing dates and/or times. Instead, the built

[issue35145] sqlite3: "select *" should optionally sniff and autoconvert TEXT datetime fields

Paul Ganssle added the comment: With regards to automatically deducing column types, I am -1 on that. It has way too many dangerous edge cases, and I know of countless bugs in software that are the direct result of stringly-typed data being coerced into a specific data type based on its

[issue35186] distutils.command.upload uses deprecated platform.dist with bdist_rpm

New submission from Paul Ganssle : It seems that in issue #1322, `platform.dist` was deprecated, and is slated for removal in Python 3.8, but it is currently used in distutils.command.upload.upload_file: https://github.com/python/cpython/blob/6843ffe4533e9f2cde036296fd932fef6f059687/Lib

[issue35081] Move internal headers to Include/internal/

Change by Paul Ganssle : -- pull_requests: +9696 ___ Python tracker <https://bugs.python.org/issue35081> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35186] distutils.command.upload uses deprecated platform.dist with bdist_rpm

Change by Paul Ganssle : -- keywords: +patch pull_requests: +9694 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35186> ___ ___ Py

[issue35171] test_TimeRE_recreation_timezone failure on systems with non-default posixrules

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

[issue35190] collections.abc.Sequence cannot be used to test whether a class provides a particular interface

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

[issue34735] Modules/timemodule.c: Memory leak in time_strftime()

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

[issue35364] Datetime “fromtimestamp()” ignores inheritance if timezone is not None

Paul Ganssle added the comment: > This is not easy problem, ant it doesn't have right solution. Different > decisions were made for the result type of alternate constructors and > operators for different classes. It's certainly true that it occasionally makes sense to do somet

[issue35364] Datetime “fromtimestamp()” ignores inheritance if timezone is not None

Paul Ganssle added the comment: Another thing to note: I'm pretty sure this was a mistake in the first place. There are many examples of places where the datetime module was just not designed with inheritance in mind, for example: - issue 32404 / issue 32403 - fromtimestamp not calling

[issue20371] datetime.datetime.replace bypasses a subclass's __new__

Paul Ganssle added the comment: This issue was fixed in Python 3.7, and it turns out issue 31222 was a duplicate of it. It can be closed now. -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue20

[issue32417] fromutc does not respect datetime subclasses

Change by Paul Ganssle : -- keywords: +patch pull_requests: +10142 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue32417> ___ ___ Py

[issue35364] Datetime “fromtimestamp()” ignores inheritance if timezone is not None

Change by Paul Ganssle : -- keywords: +patch pull_requests: +10143 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35364> ___ ___ Py

[issue35406] calendar.nextmonth and calendar.prevmonth functions doesn't check if the month is valid

Paul Ganssle added the comment: Might it be worth moving `nextmonth` and `prevmonth` to `calendar._nextmonth` and `calendar._prevmonth` to make it more clear that these are private methods? Due to Hyrum's Law, people will be using them anyway, but it could have a short deprecation period

[issue35364] Datetime “fromtimestamp()” ignores inheritance if timezone is not None

Paul Ganssle added the comment: This is another manifestation of issue 32417. The biggest complication, to me, is that adding a `timedelta` to a datetime always returns a `datetime.datetime` rather than the subclass that it was added to. I *think* most if not all people would consider

[issue22005] datetime.__setstate__ fails decoding python2 pickle

Paul Ganssle added the comment: I'm not sure I agree with how this was resolved. We're adding complexity to the datetime unpickler to support unpickling pickles created in Python 2 in Python 3? I also don't really understand the encoding parts of it, but it smells very fishy to me. I agree

[issue22005] datetime.__setstate__ fails decoding python2 pickle

Paul Ganssle added the comment: @Serhiy Any chance we can roll these back before the release so that they can have some time for discussion? I have serious concerns about having to support some Python 2/3 compatibility hack in datetime for the next 6 years. If this is worth doing at all, I

[issue22005] datetime.__setstate__ fails decoding python2 pickle

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

[issue22005] datetime.__setstate__ fails decoding python2 pickle

Paul Ganssle added the comment: I do not care enough about this to fight about it. The issue has been open long enough that I do not think it justified the urgency of rushing through a patch just before the release and merging without review, but now that it is in the release of multiple

[issue32417] fromutc does not respect datetime subclasses

Paul Ganssle added the comment: Ah, that's my mistake. I have always been under the impression that "Versions" meant "versions affected", not "versions that this needs to be fixed for". I usually just selected the ones where I had verified that it's a proble

[issue32417] fromutc does not respect datetime subclasses

Paul Ganssle added the comment: I am somewhat uneasy about backporting this to Python 2.7 because changing the return type of `SomeDateTime + timedelta` could be seen as a breaking change. I have sent a message to the datetime-SIG mailing list about this for more visibility

[issue32417] fromutc does not respect datetime subclasses

Paul Ganssle added the comment: > What's the use case for subclassing DateTime? These classes were not designed > with subclassing as a use case in mind. There are several reasons for doing it, of various levels of legitimacy. The overall theme is that people want different behavior

[issue35385] time module: why not using tzname from the glibc?

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

[issue35327] Using skipTest with subTest gives a misleading UI.

New submission from Paul Ganssle : It seems that if you call skipTest *anywhere* in a test function, even in a subTest, the *entire* function gets marked as "skipped", even if only one sub-test is skipped. Example: import unittest class SomeTest(unittest.TestCase):

[issue35327] Using skipTest with subTest gives a misleading UI.

Paul Ganssle added the comment: As "prior art" the way that pytest does this is to have parametrized tests show up as separate tests: import pytest @pytest.mark.parametrize("i", range(1, 3)) def test_something(i): if i > 1: pyt

[issue35327] Using skipTest with subTest gives a misleading UI.

Paul Ganssle added the comment: @Rémi Interesting. Your suggested output does look clearer than the existing one, but it still doesn't indicate that anything *passed*. I think I like the way pytest does it the best, but if we can't expose the subtests as separate tests, I'd probably want

[issue35317] test_email: test_localtime_daylight_false_dst_true() fails depending on the timezone

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

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Paul Ganssle added the comment: I agree with Victor on this. In the future, I'd really like to see us do our best to add cross-platform uniformity to Python's strftime and strptime support. If there really is a platform out there that doesn't support a trailing `%`, I like the idea

[issue35723] Add "time zone index" cache to datetime objects

New submission from Paul Ganssle : When examining the performance characteristics of pytz, I realized that pytz's eager calculation of tzname, offset and DST gives it an implicit cache that makes it much faster for repeated queries to .utcoffset(), .dst() and/or .tzname() though the eager

[issue35723] Add "time zone index" cache to datetime objects

Change by Paul Ganssle : -- keywords: +patch pull_requests: +11122 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35723> ___ ___ Py

[issue35723] Add "time zone index" cache to datetime objects

Paul Ganssle added the comment: One other thing I might mention here is that I did explore the idea of storing this cache on the tzinfo implementation itself, but it is problematic for a number of reasons: 1. It would either need to use some sort of expiring cache (lru, ttl) or require

[issue35723] Add "time zone index" cache to datetime objects

Paul Ganssle added the comment: > I dislike adding a public API for an optimization. Would it be possible to > make it private? Would it make sense? tzidx => _tzidx. This also would have been my preference, but it is unfortunately not possible because of the way tzinfo work

[issue33052] Sporadic segmentation fault in test_datetime

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

[issue34676] Guarantie that divmod() and PyNumber_Divmod() return a 2-tuple

Paul Ganssle added the comment: I would be somewhat worried that this might break something like numpy (though not numpy specifically) which might be counting on the ability to write a wrapper that overloads this behavior. Another concern is that people could be playing it fast-and-loose

[issue34672] '%Z' strftime specifier never works with musl

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

[issue31635] test_strptime failure on OpenBSD

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

[issue32313] Wrong inspect.getsource for datetime

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

[issue33259] Encoding issue in the name of the local DST timezone

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

[issue34672] '%Z' strftime specifier never works with musl

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

[issue31635] test_strptime failure on OpenBSD

Paul Ganssle added the comment: This appears to be a duplicate of issue #13414, which was resolved as fixed in BSD. @serhiy Are you using a very old version of BSD? -- ___ Python tracker <https://bugs.python.org/issue31

[issue32313] Wrong inspect.getsource for datetime

Paul Ganssle added the comment: I think this is *mostly* the correct behavior (though it may indeed be confusing). Note that `datetime.py` *is* the source of the module `datetime`, it's just that most of the code in there is shadowed by the line you've linked. If you try and get the source

[issue31635] test_strptime failure on OpenBSD

Paul Ganssle added the comment: I think this is the relevant test: https://github.com/python/cpython/blob/3.7/Lib/test/test_strptime.py#L536 The issue seems to be in `strftime` rather than in `strptime`. According to Serhiy's paste, it seems that `datetime.datetime.strftime("%G

[issue34715] timemodule.c fails to compile on BSD

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

[issue34716] MagicMock.__divmod__ should return a pair

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

[issue34676] Guarantee that divmod() and PyNumber_Divmod() return a 2-tuple

Paul Ganssle added the comment: @Serhiy I like the "convert to a tuple" idea before returning *better*, though I think I'd prefer to just check that it's tuple-like, something like: if not all(hasattr(return_val, attr) for attr in ['__getitem__', '__len__']) or len(return

[issue31635] test_strptime failure on OpenBSD

Paul Ganssle added the comment: @Serhiy Looking more closely at #13414, I think there's a good chance that we've just discovered a different bug in OpenBSD's implementation of wcsftime (or strftime). Looks like OpenBSD 6.1 was released in 2017, which should have been years after the fix

[issue31635] test_strptime failure on OpenBSD

Paul Ganssle added the comment: Bug reported to BSD here: https://marc.info/?l=openbsd-bugs=153728102618747=2 -- ___ Python tracker <https://bugs.python.org/issue31

[issue31635] test_strptime failure on OpenBSD

Paul Ganssle added the comment: I do think this is an active bug in OpenBSD's ISO calculations, here: https://github.com/openbsd/src/blob/b66614995ab119f75167daaa7755b34001836821/lib/libc/time/wcsftime.c#L326 I re-created this algorithm in Python and at the beginning of the year it gives

[issue35535] time.strptime() unexpectedly gives the same result for %U and %W for 2018

Paul Ganssle added the comment: I don't really know what Python was doing in version 2.3, and I don't have immediate access to a Python 2.3 interpreter, but at least for %U and %W, datetime is calling the platform's `strftime` under the hood, so presumably if this is a bug it's a bug

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

Paul Ganssle added the comment: > It seems a little odd to need to pull in a third-party library for this; it > seems far more tempting for me to just do > "datetime.fromisoformat(str.replace('Z', '+00:00'))" instead since I know my > dates are produced by a JSON A

[issue35841] Datetime strftime() does not return correct week numbers for 2019

Paul Ganssle added the comment: Possibly related to 35535. -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue35841> ___ ___ Python-bugs-list m

[issue35841] Datetime strftime() does not return correct week numbers for 2019

Paul Ganssle added the comment: I think this is not a bug. bpo-35535 is probably also intended behavior, but that is less certain. The misunderstanding here is that %W does not give you the ISO week number, from the documentation: %W: Week number of the year (Monday as the first day

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

Paul Ganssle added the comment: @tin utcnow is a semi-deprecated way to get a naive datetime that represents the time in UTC. The preferred replacement is to do this: from datetime import datetime, timezone datetime.now(tz=timezone.utc) Note that you can replace "timezon

[issue31327] bug in dateutil\tz\tz.py

Paul Ganssle added the comment: Can we change the title of this to something like, "Add example of platform-specific support for negative timestamps to the time documentation"? That might be a bit wordy, but as it is now, this looks like it's reporting a bug in dateutil, which i

[issue36439] Inconsistencies with datetime.fromtimestamp(t) when t < 0

Paul Ganssle added the comment: >From the documentation ( >https://docs.python.org/3/library/datetime.html#datetime.datetime.fromtimestamp > ): > fromtimestamp() may raise OverflowError, if the timestamp is out of the range > of values supported by the platform C localt

[issue33632] undefined behaviour: signed integer overflow in threadmodule.c

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

[issue36558] Change time.mktime() return type from float to int?

Paul Ganssle added the comment: I would say that the natural output of mktime is indeed an integer, but I can't say off the top of my head what "compatibility" refers to here, so per the principle of Chesterton's fence, without more research or historical context I'd say the defa

[issue36564] Infinite loop with short maximum line lengths in EmailPolicy

New submission from Paul Ganssle : When reviewing PR 12020 fixing an infinite loop in the e-mail module, I noticed that a *different* infinite loop is documented with a "# XXX" comment on line 2724: https://github.com/python/cpython/blob/58721a903074d28151d008d8990c98fc31d1e798

[issue36564] Infinite loop with short maximum line lengths in EmailPolicy

Change by Paul Ganssle : -- keywords: +patch pull_requests: +12655 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36564> ___ ___ Py

[issue24643] VS 2015 pyconfig.h #define timezone _timezone conflicts with timeb.h

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

[issue36122] Second run of 2to3 continues to modify output

Paul Ganssle added the comment: Because what's being printed is a tuple, I think it's not exactly the same as issue35417, because in fact this is the correct behavior for 2to3, note that in Python 2: Python 2.7.15 (default, Jul 21 2018, 11:13:03) >>> print 1, 2 1 2 >>>

[issue36145] android arm cross compilation fails, config issue

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

[issue36138] Improve documentation about converting datetime.timedelta to scalars

New submission from Paul Ganssle : In a recent python-dev thread, there was some confusion about how to get something like `timedelta.total_microseconds()`. There is already an existing, supported idiom for this, which is that `timedelta` implements division: td = timedelta(hours=1

[issue35417] Double parenthesis in print function running 2to3 in already correct call

Paul Ganssle added the comment: > 2to3 is designed as a tool to convert a Python 2 code base to Python 3 at > once. I understand that once the code base is converted, you may want to > revert some unwanted "useless" changes. While this problem is likely to show up beca

[issue23607] Inconsistency in datetime.utcfromtimestamp(Decimal)

Paul Ganssle added the comment: Oh actually that's my mistake. I can't reproduce the failure in the constructor in the Python version of the module, and also it seems to be fixed in the pure Python version as of at least 3.6: Python 3.6.7 (default, Oct 25 2018, 16:11:17) [GCC 8.2.1

[issue15237] Add capsule API to _decimal

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

[issue23607] Inconsistency in datetime.utcfromtimestamp(Decimal)

Paul Ganssle added the comment: I'm not sure if either of these patches got merged, but at some point this was fixed: Python 3.7.2 (default, Feb 9 2019, 13:18:43) [GCC 8.2.1 20181127] on linux Type "help", "copyright", "credits" or "license&

[issue22194] access to cdecimal / libmpdec API

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

[issue36330] Warning about a potential dead code in timemodule and Clang

Paul Ganssle added the comment: Sorry, I should say unlikely that it should ever be *true*. It seems unlikely that there is a platform or piece of hardware on which this error would be raised. -- ___ Python tracker <https://bugs.python.

[issue36330] Warning about a potential dead code in timemodule and Clang

Paul Ganssle added the comment: It does seem like the values CLOCKS_PER_SEC, _PyTime_MAX and SEC_TO_NS are all defined at compile-time, so presumably this can be a compile-time error. As currently defined, though, it seems very unlikely that this would ever be false, since _PyTime_MAX

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Paul Ganssle added the comment: I think the proposed change to the test will work, or we can mark the test as an expected failure on Android (on the theory that the test *should* work because we want the behavior normalized, but we are not living up to that). In either case, I think

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Paul Ganssle added the comment: > No please, don't do that :-( Interesting, I don't feel terribly strongly about it, but I would have thought that you'd be more in favor of that solution, maybe we have a different definition of "expected failure"? Usually in my projects, I u

[issue36240] Definitions of time

Paul Ganssle added the comment: I also think it would be ideal to avoid getting into too much detail about the definitions of UTC and GMT in a general sense. Instead, we should probably refer to some better source on the matter and maybe focus on how UTC and GMT are used *in this document

[issue32417] fromutc does not respect datetime subclasses

Paul Ganssle added the comment: Ah, sorry for the noise, this is a known issue: https://github.com/python/bugs.python.org/issues/12 -- ___ Python tracker <https://bugs.python.org/issue32

[issue35364] Datetime “fromtimestamp()” ignores inheritance if timezone is not None

Change by Paul Ganssle : -- pull_requests: +11794, 11795 ___ Python tracker <https://bugs.python.org/issue35364> ___ ___ Python-bugs-list mailing list Unsub

[issue32417] fromutc does not respect datetime subclasses

Change by Paul Ganssle : -- pull_requests: +11790, 11791, 11792, 11793 ___ Python tracker <https://bugs.python.org/issue32417> ___ ___ Python-bugs-list mailin

[issue32417] fromutc does not respect datetime subclasses

Change by Paul Ganssle : -- pull_requests: +11790, 11791 ___ Python tracker <https://bugs.python.org/issue32417> ___ ___ Python-bugs-list mailing list Unsub

[issue32417] fromutc does not respect datetime subclasses

Change by Paul Ganssle : -- pull_requests: +11790, 11791, 11792 ___ Python tracker <https://bugs.python.org/issue32417> ___ ___ Python-bugs-list mailin

[issue32417] fromutc does not respect datetime subclasses

Change by Paul Ganssle : -- pull_requests: +11790 ___ Python tracker <https://bugs.python.org/issue32417> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35364] Datetime “fromtimestamp()” ignores inheritance if timezone is not None

Change by Paul Ganssle : -- pull_requests: +11794 ___ Python tracker <https://bugs.python.org/issue35364> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32417] fromutc does not respect datetime subclasses

Paul Ganssle added the comment: Hm, when I made the "What's new" issue, it added the same PR to the "Pull requests" 4 times instead of once, and in the history it seems like it *tried* to actually add PR 11790, 11791, 11792 and 11793 (only the first one exists at the m

[issue35943] PyImport_GetModule() can return partially-initialized module

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

[issue36004] Add datetime.fromisocalendar

Paul Ganssle added the comment: The attached PR is more or less fully ready, I think the correct answers to 1, 3 and 4 are that we should go with 3 separate arguments and we should not allow either time components or tz components, at least in this version. In the future, I don't think

<    1   2   3   4   5   >