[Tim]
>> However, the _body_ of the PEP said nothing whatsoever about altering
>> arithmetic. The body of the PEP sounds like it's mainly just
>> proposing to fold the pytz package into the core. Perhaps doing
>> _just_ that much would get this project unstuck? Hope springs eternal :-)
[Lennart
[ISAAC J SCHWABACHER ]
>>> ...
>>> I think the right perspective is that a time zone *is* the function that its
>>> `fromutc()` method implements,
[Tim]
>> Fine by me ;-)
[Isaac]
> My issue is that you're computing `fromutc()`, which is a function, in
> terms of `dst()` and `utcoffset()`, which a
At the risk of being off-topic, I realize I really DO NOT currently
understand datetime in its current incarnation. It's too bad PEP 431
proves so difficult to implement.
Even using `pytz` is there any way currently to get sensible answers to,
e.g.:
from datetime import *
from pytz import timezo
On Sun, Jul 26, 2015 at 2:56 AM, Tim Peters wrote:
> However, the _body_ of the PEP said nothing whatsoever about altering
> arithmetic. The body of the PEP sounds like it's mainly just
> proposing to fold the pytz package into the core. Perhaps doing
> _just_ that much would get this project un
[Lennart Regebro ]
>>> And I would want to remind everyone again that this is not a question
>>> of the problem being impossible. It's just really complex to get right
>>> in all cases, and that always having the UTC timestamp around gets rid
>>> of most of that complexity.
[Tim]
>> Could you plea
> From: Tim Peters
> Sent: Friday, July 24, 2015 20:39
> To: ISAAC J SCHWABACHER
> Cc: Alexander Belopolsky; Lennart Regebro; Python-Dev
> Subject: Re: [Python-Dev] Status on PEP-431 Timezones
>
> [ISAAC J SCHWABACHER ]
> > ...
> > I disagree with the view Tim had of time zones when he wrote that
On 21 July 2015 at 19:40, Nick Coghlan wrote:
> All of this is why the chart that I believe should be worrying people
> is the topmost one on this page:
> http://bugs.python.org/issue?@template=stats
>
> Both the number of open issues and the number of open issues with
> patches are steadily tren
> On Jul 25, 2015, at 09:15, Alexander Belopolsky
> wrote:
>
>
>> On Sat, Jul 25, 2015 at 2:40 AM, Lennart Regebro wrote:
>> There really is a reason every other date time implementation I know
>> of uses UTC internally, and there really is a reason why everyone
>> always recommends storing d
Hi,
On 22/07/15 09:25, Ronald Oussoren wrote:> Hi,
>
> Another summer with another EuroPython, which means its time again to
> try to revive PEP 447…
>
IMO, there are two main issues with the PEP and implementation.
1. The implementation as outlined in the PEP is infinitely recursive, since t
On Sat, Jul 25, 2015 at 2:40 AM, Lennart Regebro wrote:
> There really is a reason every other date time implementation I know
> of uses UTC internally, and there really is a reason why everyone
> always recommends storing date times in UTC with the time zone or
> offset separately.
>
Current da
I’ve pushed a minor update to the PEP to the repository. The benchmark results
are still out of date, I need want to run those on an idle machine to get
reliable results.
The PEP has one significant change w.r.t. the previous version: it now requires
the use of a new type flag to enable the usa
11 matches
Mail list logo
