[issue15873] datetime: add ability to parse RFC 3339 dates and times

2017-12-04 Thread Paul Ganssle
Paul Ganssle <p.gans...@gmail.com> added the comment: > The better is the enemy of the good here. Given the history of this issue, I > would rather accept a well documented restrictive parser than wait for a more > general code to be written. Note that we can always relax th

[issue15873] datetime: add ability to parse RFC 3339 dates and times

2017-12-04 Thread Paul Ganssle
Paul Ganssle <p.gans...@gmail.com> added the comment: > The other difference is Mattieu guarantees ValueError for invalid input > strings, which I think is good. I forgot to address this - but I don't think this is a difference in approaches. If you pass `None` or an int

[issue15873] datetime: add ability to parse RFC 3339 dates and times

2017-12-04 Thread Paul Ganssle
Change by Paul Ganssle <p.gans...@gmail.com>: -- pull_requests: +4611 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue15873> ___ _

[issue15873] datetime: add ability to parse RFC 3339 dates and times

2017-12-18 Thread Paul Ganssle
Paul Ganssle <p.gans...@gmail.com> added the comment: > Not if the time is associated with a particular day. Imagine implementing > datetime.fromisoformat by separately calling date.fromisoformat and > time.fromisoformat. The date will be off by one day if you naively rounded

[issue5288] tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28)

2017-12-12 Thread Paul Ganssle
Change by Paul Ganssle <p.gans...@gmail.com>: -- pull_requests: +4721 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue5288> ___ _

[issue15873] datetime: add ability to parse RFC 3339 dates and times

2017-12-17 Thread Paul Ganssle
Paul Ganssle <p.gans...@gmail.com> added the comment: @martin.panter I don't see the problem here? Wouldn't 23:59.995 round up to 00:00? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue32213] assertRaises and subTest context managers cannot be nested

2017-12-04 Thread Paul Ganssle
New submission from Paul Ganssle <p.gans...@gmail.com>: The TestCase.assertRaises and TestCase.subTest macros apparently don't interact with each other well. To demonstrate, consider the following code: from unittest import TestCase class SubTestRaisesTest(TestCase):

[issue32213] assertRaises and subTest context managers cannot be nested

2017-12-04 Thread Paul Ganssle
Paul Ganssle <p.gans...@gmail.com> added the comment: @r.david.murray So it is, my mistake. I think I was conflating issues when this first came up, and then I didn't notice that the order the test cases printed in was different than I expected. -- stage: -> resolved sta

[issue31222] datetime.py implementation of .replace inconsistent with C implementation

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

[issue31222] datetime.py implementation of .replace inconsistent with C implementation

2017-10-30 Thread Paul Ganssle
Paul Ganssle <p.gans...@gmail.com> added the comment: Some time ago this was fixed in pypy3: https://bitbucket.org/pypy/pypy/issues/2635/datetimereplace-always-returns I made a PR fixing this for `datetime`, `date` and `time`. -- ___ Python t

[issue33400] logging.Formatter does not default to ISO8601 date format

2018-05-15 Thread Paul Ganssle
Paul Ganssle <p.gans...@gmail.com> added the comment: I don't really agree with these changes to the documentation. The format that paulc identifies is actually an RFC 3339 datetime, which is a subset of ISO 8601, to the extent that you consider the fact that "we're using RFC 3339&

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

2018-06-05 Thread Paul Ganssle
Change by Paul Ganssle : -- keywords: +patch pull_requests: +7050 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issu

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

2018-06-05 Thread Paul Ganssle
Paul Ganssle added the comment: So I created a little patch for this, and when I was working on it I realized that it's actually possible to implement full `fold` support in a generic way in `fromutc` under the assumption that `utcoffset - dst` holds at all points (which is the fundamental

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

2018-06-05 Thread Paul Ganssle
Paul Ganssle added the comment: > I am aware of that. In fact, some of the draft versions of PEP 495 > implementation did contain such code. The problem is that any such > tz.fromutc() implementation would necessarily change the behavior of the old > programs. This I'm no

[issue33400] logging.Formatter does not default to ISO8601 date format

2018-05-28 Thread Paul Ganssle
Paul Ganssle <p.gans...@gmail.com> added the comment: I think this is more a matter of misunderstanding the fact that ISO 8601 is a larger and more complicated spec than people think. You'll note that the original complaint also seems to think that a timezone is required (it is not). Y

[issue33400] logging.Formatter does not default to ISO8601 date format

2018-05-28 Thread Paul Ganssle
Paul Ganssle <p.gans...@gmail.com> added the comment: Ah, actually, my mistake, RFC 3339 most assuredly *does* require a UTC offset: 4.4. Unqualified Local Time A number of devices currently connected to the Internet run their internal clocks in local time and are unaware

[issue33400] logging.Formatter does not default to ISO8601 date format

2018-05-01 Thread Paul Ganssle
Paul Ganssle <p.gans...@gmail.com> added the comment: ISO 8601 does not require an offset (in fact, most portions of the ISO 8601 date and time are optional - ISO 8601 is more complicated than most people think). Without an offset a datetime is assumed to be local time. The T del

[issue10381] Add timezone support to datetime C API

2017-12-30 Thread Paul Ganssle
Paul Ganssle <p.gans...@gmail.com> added the comment: @Nick I'm certainly fine with re-configuring my PR to center around a new capsule module with deprecation of the old C API (though if you have any examples of what you have in mind that would be helpful to me). Certainly the &qu

[issue32497] datetime.strptime creates tz naive object from value containing a tzname

2018-01-05 Thread Paul Ganssle
Paul Ganssle <p.gans...@gmail.com> added the comment: By the way, one possibly significant problem with this interface is that it would tend to encourage the use of static timezone offsets rather than rule sets as intended by `tzinfo`. The main problem is that a simple mapping between

[issue32497] datetime.strptime creates tz naive object from value containing a tzname

2018-01-05 Thread Paul Ganssle
Paul Ganssle <p.gans...@gmail.com> added the comment: This is essentially what the `tzinfos` argument to `dateutil.parser.parse` does. I do think something *like* this is the only reasonable way to handle %Z->tzinfo mappings. In `dateutil` (https://dateutil.readthedocs.io/

[issue30541] Add restricted mocks to the python unittest mocking framework

2018-01-05 Thread Paul Ganssle
Change by Paul Ganssle <p.gans...@gmail.com>: -- pull_requests: +4974 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue30541> ___ _

[issue32497] datetime.strptime creates tz naive object from value containing a tzname

2018-01-05 Thread Paul Ganssle
Paul Ganssle <p.gans...@gmail.com> added the comment: Sorry, forgot to include the link to the dateutil implementation of the fold-resolution code: https://github.com/dateutil/dateutil/pull/517/files -- ___ Python tracker <rep...@bugs.p

[issue32404] fromtimestamp does not call __new__ in datetime subclasses

2017-12-21 Thread Paul Ganssle
New submission from Paul Ganssle <p.gans...@gmail.com>: In writing some tests for the alternate date constructors as part of my PR for issue 32403 (https://bugs.python.org/issue32403), I noticed that for `datetime`, the `fromtimestamp` bypasses the `__new__` call on the subclass:

[issue32403] date, time and datetime alternate constructors should take fast construction path

2017-12-21 Thread Paul Ganssle
New submission from Paul Ganssle <p.gans...@gmail.com>: In the addition of the `fromisoformat()` alternate constructor (bpo-15873: https://github.com/python/cpython/pull/4699), I noted that I was able to get some significant speedup by special-casing the `datetime` baseclass in the C c

[issue32403] date, time and datetime alternate constructors should take fast construction path

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

[issue32404] fromtimestamp does not call __new__ in datetime subclasses

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

[issue32417] fromutc does not respect datetime subclasses

2017-12-23 Thread Paul Ganssle
New submission from Paul Ganssle <p.gans...@gmail.com>: When preparing some tests for how subclasses of date and datetime react as part of a fix for issue 32403, I noticed a fairly big example of where subclass is not preserved - `tzinfo.fromutc`: from datetime import datetime, ti

[issue32417] fromutc does not respect datetime subclasses

2017-12-23 Thread Paul Ganssle
Paul Ganssle <p.gans...@gmail.com> added the comment: I've noticed that there's another complicating factor here, which is that addition of `timedelta` does not respect subclasses either, which means that third party libraries implementing fromutc (as was recommended in issue 28602)

[issue32522] Add precision argument to datetime.now

2018-01-09 Thread Paul Ganssle
Paul Ganssle <p.gans...@gmail.com> added the comment: One thing to note, the "example implementation" of __round__ above is an actual working prototype*: >>> round(Datetime.now(), 'second') Datetime(2018, 1, 9, 11, 59, 35) >>> round(Datetime.now(), 'day') Dat

[issue32522] Add precision argument to datetime.now

2018-01-09 Thread Paul Ganssle
Paul Ganssle <p.gans...@gmail.com> added the comment: > Looking at the dateutil, I don't see a truncate to rrule function. Maybe a > good starting point would be to implement that in dateutil and if some > simpler pattern emerges that can be proposed for stdlib, we can discuss

[issue32522] Add precision argument to datetime.now

2018-01-09 Thread Paul Ganssle
Paul Ganssle <p.gans...@gmail.com> added the comment: > This can be accomplished rather efficiently by truncating a time tuple: This will not preserve tzinfo, and (though this is not a concern unless nanosecond precision is added), I don't believe it preserves microseconds either.

[issue32522] Add precision argument to datetime.now

2018-01-09 Thread Paul Ganssle
Paul Ganssle <p.gans...@gmail.com> added the comment: I think if we're going to use `timedelta` then `__mod__` is the more appropriate option here, since it would be hard to interpret what `round(dt, timedelta(hours=2, microseconds=31))` would do. Either __mod__ or __round__ with `tim

[issue32522] Add precision argument to datetime.now

2018-01-09 Thread Paul Ganssle
Paul Ganssle <p.gans...@gmail.com> added the comment: > In my experience, when dealing with temporal data truncation (rounding > towards -infinity) is more useful than any other form of rounding. See also > issue 19475. Ah, I agree - if you see that's how my __round__ implemen

[issue32522] Add precision argument to datetime.now

2018-01-09 Thread Paul Ganssle
Paul Ganssle <p.gans...@gmail.com> added the comment: > Still, this feature is not appealing enough to try to squeeze into 3.7 > release schedule. I think this should go through a round of discussion > either on datetime-sig or python-ideas. Agreed. I will put togeth

[issue32522] Add precision argument to datetime.now

2018-01-09 Thread Paul Ganssle
New submission from Paul Ganssle <p.gans...@gmail.com>: One thing I think that is fairly common is the desire to get the current datetime only up to a current precision, so you see a lot of things in, say, `dateutil` like this: dt = datetime.now().replace(hours=0, minutes=0, sec

[issue32522] Add precision argument to datetime.now

2018-01-09 Thread Paul Ganssle
Paul Ganssle <p.gans...@gmail.com> added the comment: An alternate possibility here might be to implement either `__round__` or a `round` function in `datetime` (which would basically automatically add this precision functionality to *all* the constructors, not just now). An e

[issue32522] Add precision argument to datetime.now

2018-01-09 Thread Paul Ganssle
Paul Ganssle <p.gans...@gmail.com> added the comment: @Victor: With regards to getting a "date as datetime", that is another way to do it that I have also done in the past (and in fact it's how the new dateutil.utils.today() function is implemented: https://github.com/dateut

[issue32522] Add precision argument to datetime.now

2018-01-09 Thread Paul Ganssle
Change by Paul Ganssle <p.gans...@gmail.com>: -- type: -> enhancement ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32522> ___ _

[issue32522] Add precision argument to datetime.now

2018-01-09 Thread Paul Ganssle
Paul Ganssle <p.gans...@gmail.com> added the comment: @Barry I don't think it's a good idea to duplicate the `replace` functionality in `datetime` like that. I think the main problem isn't the `.replace`, it's the fact that you have to specify exactly which components you want to set to

[issue25330] Docs for pkgutil.get_data inconsistent with semantics

2018-01-26 Thread Paul Ganssle
Paul Ganssle <p.gans...@gmail.com> added the comment: I'm not sure if this warrants a separate issue, but I also notice this in the documentation: > If the package cannot be located or loaded, or it uses a loader which does > not support get_data, then None is returned. I

[issue10381] Add timezone support to datetime C API

2018-01-25 Thread Paul Ganssle
Change by Paul Ganssle <p.gans...@gmail.com>: -- pull_requests: +5164 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue10381> ___ _

[issue10381] Add timezone support to datetime C API

2018-01-25 Thread Paul Ganssle
Change by Paul Ganssle <p.gans...@gmail.com>: -- pull_requests: +5163 stage: resolved -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue15873] datetime: add ability to parse RFC 3339 dates and times

2018-02-05 Thread Paul Ganssle
Change by Paul Ganssle <p.gans...@gmail.com>: -- pull_requests: +5380, 5381 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue15873] datetime: add ability to parse RFC 3339 dates and times

2018-02-05 Thread Paul Ganssle
Change by Paul Ganssle <p.gans...@gmail.com>: -- pull_requests: +5380 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue15873> ___ _

[issue32403] date, time and datetime alternate constructors should take fast construction path

2018-02-22 Thread Paul Ganssle
Change by Paul Ganssle <p.gans...@gmail.com>: -- pull_requests: +5589 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32403> ___ _

[issue10381] Add timezone support to datetime C API

2018-02-22 Thread Paul Ganssle
Change by Paul Ganssle <p.gans...@gmail.com>: -- pull_requests: +5588 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue10381> ___ _

[issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation

2017-12-28 Thread Paul Ganssle
Paul Ganssle <p.gans...@gmail.com> added the comment: > I mean dropping `.copy()` breaks not only compatibility between pure python > versions but also between pypy releases and pypy/CPython code. That's why I suggest to keep `.copy()` as an alias for `__copy__()`. If th

[issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation

2017-12-28 Thread Paul Ganssle
Paul Ganssle <p.gans...@gmail.com> added the comment: @Andrew Are you suggesting that a `copy` method be *added* to the C implementation, as an alias to __copy__? Because it makes no sense to keep the pure Python and C implementations out of sync just so that it's easier for projects f

[issue32424] Rename copy() to __copy__() in xml.etree.ElementTree.Element Python implementation

2017-12-28 Thread Paul Ganssle
Paul Ganssle <p.gans...@gmail.com> added the comment: > There is no "fork" involved in other projects using it, from our point of > view. I did not mean "fork" in some judgmental sense, I'm mostly just familiar with pypy, but I was under the impression tha

[issue10381] Add timezone support to datetime C API

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

[issue10381] Add timezone support to datetime C API

2017-12-28 Thread Paul Ganssle
Change by Paul Ganssle <p.gans...@gmail.com>: -- nosy: +p-ganssle ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue10381> ___ _

[issue34416] PyCapsule_Import seems to release the GIL without acquiring it

2018-08-16 Thread Paul Ganssle
New submission from Paul Ganssle : I was recently debugging some multithreaded Rust code that was deadlocking, and I tracked it down to what I'm fairly certain is a bug somewhere in PyCapsule_Import, where it seems that PyCapsule_Import releases the GIL without first acquiring it. I've

[issue34416] PyCapsule_Import seems to release the GIL without acquiring it

2018-08-16 Thread Paul Ganssle
Paul Ganssle added the comment: Using a modified version of Python 3.7.0 that prints "Releasing GIL" whenever PyGILState_Release, I get this: Waiting for GIL (0) Gil acquired! (0) Waiting for GIL (1) Gil acquired! (1) Releasing GIL Gil released! (0) Releasing GIL Gil release

[issue34416] PyCapsule_Import seems to release the GIL without acquiring it

2018-08-17 Thread Paul Ganssle
Paul Ganssle added the comment: > It does not seem to me that two threads have the GIL at the same time. To be clear, this was never my contention. I was under the impression that if you take the GIL with PyGILState_Ensure(), the GIL was held until you called PyGILState_Rele

[issue34365] datetime's documentation refers to "comparison [...] falling back to the default scheme of comparing object addresses"

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

[issue34404] test_time incorrectly defined

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

[issue1100942] Add datetime.time.strptime and datetime.date.strptime

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

[issue34407] datetime.time.isoformat function has inconsistent behavior with timezone

2018-08-20 Thread Paul Ganssle
Paul Ganssle added the comment: For one thing, this is not how pytz is supposed to be used. You have fallen prey to one of the most common errors when using pytz. See my blog post: https://blog.ganssle.io/articles/2018/03/pytz-fastest-footgun.html The issue at hand is also more about what

[issue34454] datetime: NULL dereference in fromisoformat() on PyUnicode_AsUTF8AndSize() failure

2018-08-21 Thread Paul Ganssle
Paul Ganssle added the comment: > Note that technically a difference between C and Python implementation of > fromisoformat() will still remain: if a part of the input string before or > after the separator contains surrogates, the C code will throw a > UnicodeEncodeError whil

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

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

[issue34423] Overflow when casting from double to time_t, and_PyTime_t.

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

[issue30717] Add unicode grapheme cluster break algorithm

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

[issue34454] datetime: NULL dereference in fromisoformat() on PyUnicode_AsUTF8AndSize() failure

2018-08-21 Thread Paul Ganssle
Paul Ganssle added the comment: So this is related to something I was actually meaning to fix. When I wrote this code I didn't understand the way PyUnicode works, there's actually no need to call `PyUnicode_AsUTF8AndSize()` on the entire unicode string. My understanding is that each glyph

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

2018-08-28 Thread Paul Ganssle
Change by Paul Ganssle : -- keywords: +patch pull_requests: +8457 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34481> ___ ___ Py

[issue34454] datetime: NULL dereference in fromisoformat() on PyUnicode_AsUTF8AndSize() failure

2018-08-27 Thread Paul Ganssle
Change by Paul Ganssle : -- pull_requests: +8434 ___ Python tracker <https://bugs.python.org/issue34454> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34482] datetime: Tests for potential crashes due to non-UTF-8-encodable strings

2018-08-27 Thread Paul Ganssle
Paul Ganssle added the comment: Somewhat related: #6697. Turns out there are already some tests here for this, specifically for the C version only: https://github.com/python/cpython/blob/master/Lib/test/datetimetester.py#L3328 -- ___ Python

[issue34454] datetime: NULL dereference in fromisoformat() on PyUnicode_AsUTF8AndSize() failure

2018-08-22 Thread Paul Ganssle
Change by Paul Ganssle : -- pull_requests: +8336 ___ Python tracker <https://bugs.python.org/issue34454> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34158] Documentation of datetime '%z' format code is odd

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

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

2018-08-29 Thread Paul Ganssle
Paul Ganssle added the comment: I'm finding it very difficult to reconcile these things. I'm not entirely sure, but we may need to take a performance hit in normal strftime if we want to make this work with surrogate characters, which really does not appeal to me (though we can certainly

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

2018-08-30 Thread Paul Ganssle
Paul Ganssle added the comment: @izbyshev That's totally fair and I wouldn't want to make it a condition of merging the existing fixes - I've already made great progress in fixing the time.strftime part as well. The main reason it relates here is that I generally find the tests to be among

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

2018-09-05 Thread Paul Ganssle
Paul Ganssle added the comment: I've left a mostly finished PR on #8983, but I've decided it's not really worth continuing to work on. Anyone can feel free to take it and run with it if they want to implement the fix for this. As Alexey mentions, that PR indeed already fixes this bug, I

[issue33941] datetime.strptime not able to recognize invalid date formats

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

[issue29097] [Windows] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on Python 3.6

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

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

2018-07-05 Thread Paul Ganssle
Paul Ganssle added the comment: I believe this can be consolidated with #15873 and closed, since that is finished and available in Python 3.7. -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue24

[issue13305] datetime.strftime("%Y") not consistent for years < 1000

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

[issue22005] datetime.__setstate__ fails decoding python2 pickle

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

[issue10381] Add timezone support to datetime C API

2018-07-05 Thread Paul Ganssle
Paul Ganssle added the comment: This can be closed now, I think. -- ___ Python tracker <https://bugs.python.org/issue10381> ___ ___ Python-bugs-list mailin

[issue23607] Inconsistency in datetime.utcfromtimestamp(Decimal)

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

[issue12750] add cross-platform support for %s strftime-format code

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

[issue25729] update pure python datetime.timedelta creation

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

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

2018-07-05 Thread Paul Ganssle
Paul Ganssle added the comment: Oops, that previous comment was intended for a completely different ticket. My mistake. -- ___ Python tracker <https://bugs.python.org/issue27

[issue30155] Add ability to get/set tzinfo on datetime instances in C API

2018-07-05 Thread Paul Ganssle
Paul Ganssle added the comment: Hmm. I never noticed this. In the past I have used the (undocumented) PyDateTimeAPI struct, which the official macros wrap. I'm not sure how official that struct is considering it doesn't show up in the documentation. I agree that it should be possible

[issue15443] datetime module has no support for nanoseconds

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

[issue33381] Incorrect documentation for strftime()/strptime() format code %f

2018-07-05 Thread Paul Ganssle
Paul Ganssle added the comment: I don't believe this is a duplicate if #32267, which is actually about the %z directive. I think the implementation here is correct and the documentation is semi-correct, it depends on how you look at it, consider: >>> datetime(2018, 1, 1, 0

[issue9305] Don't use east/west of UTC in date/time documentation

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

[issue9004] datetime.utctimetuple() should not set tm_isdst flag to 0

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

[issue28730] __reduce__ not being called in dervied extension class from datetime.datetime

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

[issue34023] timedelta(seconds=x) strange results when type(x) == np.int32

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

[issue6280] calendar.timegm() belongs in time module, next to time.gmtime()

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

[issue31839] datetime: add method to parse isoformat() output

2018-07-05 Thread Paul Ganssle
Paul Ganssle added the comment: This is a duplicate of #15873 and #24954 and can be closed, as `fromisoformat()` was added in Python 3.7. -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue31

[issue16322] time.tzname on Python 3.3.0 for Windows is decoded by wrong encoding

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

[issue5516] equality not symmetric for subclasses of datetime.date and datetime.datetime

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

[issue22426] strptime accepts the wrong '2010-06-01 MSK' string but rejects the right '2010-06-01 MSD'

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

[issue27741] datetime.datetime.strptime functionality description incorrect

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

[issue33701] test_datetime crashed (SIGSEGV) on Travis CI

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

[issue33381] Incorrect documentation for strftime()/strptime() format code %f

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

[issue33940] datetime.strptime have no directive to convert date values with Era and Time Zone name

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

[issue31898] Add a `recommended-packages.txt` file

2018-07-05 Thread Paul Ganssle
Paul Ganssle added the comment: > datetime.timezone -> pytz.timezone (updates driven by IANA timezone database) I will note that `pytz.timezone` and `datetime.timezone` are not really comparable (they do two very different things), and as of Python 3.6, `dateutil.tz` is the recom

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

2018-07-05 Thread Paul Ganssle
Paul Ganssle added the comment: Hmm. I never noticed this. In the past I have used the (undocumented) PyDateTimeAPI struct, which the official macros wrap. I'm not sure how official that struct is considering it doesn't show up in the documentation. I agree that it should be possible

[issue22377] %Z in strptime doesn't match EST and others

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

  1   2   3   4   >