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
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue16322>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue25729>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue12750>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue13305>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue9305>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue33381>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue33940>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue34023>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue6280>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue15443>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue23607>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue33701>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue29097>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
This can be closed now, I think.
--
___
Python tracker
<https://bugs.python.org/issue10381>
___
___
Python-bugs-list mailin
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue33941>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +7050
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
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
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
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&
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
Change by Paul Ganssle <p.gans...@gmail.com>:
--
versions: +Python 3.8
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue28602>
___
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
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
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
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
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
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'
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
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
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
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
Change by Paul Ganssle <p.gans...@gmail.com>:
--
pull_requests: +5588
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue10381>
___
_
Change by Paul Ganssle <p.gans...@gmail.com>:
--
pull_requests: +5589
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32403>
___
_
Change by Paul Ganssle <p.gans...@gmail.com>:
--
pull_requests: +5380, 5381
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Paul Ganssle <p.gans...@gmail.com>:
--
pull_requests: +5380
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue15873>
___
_
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
Change by Paul Ganssle <p.gans...@gmail.com>:
--
pull_requests: +5164
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue10381>
___
_
Change by Paul Ganssle <p.gans...@gmail.com>:
--
pull_requests: +5163
stage: resolved -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
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
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.
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
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
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
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
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
Change by Paul Ganssle <p.gans...@gmail.com>:
--
type: -> enhancement
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32522>
___
_
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
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
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
Change by Paul Ganssle <p.gans...@gmail.com>:
--
pull_requests: +4974
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue30541>
___
_
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
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
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/
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
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
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
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
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
Change by Paul Ganssle <p.gans...@gmail.com>:
--
nosy: +p-ganssle
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue10381>
___
_
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
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
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)
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
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:
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
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
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
Change by Paul Ganssle <p.gans...@gmail.com>:
--
pull_requests: +4721
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue5288>
___
_
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
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
Change by Paul Ganssle <p.gans...@gmail.com>:
--
pull_requests: +4611
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue15873>
___
_
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
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):
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
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
401 - 482 of 482 matches
Mail list logo
