On Wednesday, 11 November 2020 at 12:22:24 UTC+1, Chris Angelico wrote:
> On Wed, Nov 11, 2020 at 10:06 PM j c wrote:
> >
> > Hello all,
> >
> > I don't know if this suggestion is missing some point, or it's part of
> > something already proposed.
>
Hello all,
I don't know if this suggestion is missing some point, or it's part of
something already proposed.
In a professional environment, we've came to a point in which most people use
virtual environments or conda environments to avoid "polluting a global
environment".
However, I think
Hello all,
I don't know if this suggestion is missing some point, or it's part of
something already proposed before.
In a professional environment, we've came to a point in which most people use
virtual environments or code environments to avoid "polluting a global
environment".
However, I
Peter J C Law added the comment:
Hi,
Sorry for the overkill demo. I've attached a much shorter version, the key
portion of which seems to be that, for the case of UK summer time the timezone,
the tzinfo's `dst()` and `utcoffset()` methods return the same value.
This results in the delta
New submission from Peter J C Law:
There's a difference in behaviour between the ``fromutc`` method on a tzinfo
between Python 2 and Python 3, though only under the specific case of Summer
Time in regions whose usual offset is 0.
From what I can tell, it's the Python 3 one which is wrong
as an
alternate ctor with a special name, and to use the types module for type
comparison within such a ctor.
--
J C LawrenceThey said, You have a blue guitar,
-(*)You do not play things as they are.
[EMAIL PROTECTED] The man replied
