[Python-Dev] Status on PEP-431 Timezones

Alexander Belopolsky alexander.belopolsky at gmail.com
Mon Jul 27 18:42:55 CEST 2015


On Mon, Jul 27, 2015 at 12:30 PM, Lennart Regebro <regebro at gmail.com> wrote:

> On Mon, Jul 27, 2015 at 6:15 PM, Nikolaus Rath <Nikolaus at rath.org> wrote:
> > On Jul 27 2015, Lennart Regebro <regebro at gmail.com> wrote:
>
(The *first* option)

> >> That you add one hour to it, and the datetime moves forward one hour
> >> in actual time? That's doable, but during certain circumstance this
> >> may mean that you go from 1AM to 1AM, or from 1AM to 3AM.
> >>
>
(The *second* option)

> >> Or do you expect that adding one hour will increase the hour count
> >> with one, ie that the "wall time" increases with one hour? ...
> > Can you tell us which of the two operations datetime currently
> > implements?
>
> It's intended that the first one is implemented, meaning that
> datetime.now() + timedelta(hours=24) can result in a datetime
> somewhere between 23 and 25 hours into the future.


I think this describes what was originally your *second*, not *first*
option. It
will also help if you focus on one use case at a time.  Your original
example
dealt with adding 1 hour, but now you switch to adding 24.

In my previous email, I explained what is currently doable using the
datetime
module:

>>> t = datetime(2014,11,2,5,tzinfo=timezone.utc).astimezone()
>>> t.strftime("%D %T%z %Z")
'11/02/14 01:00:00-0400 EDT'
>>> (t+timedelta(hours=1)).astimezone().strftime("%D %T%z %Z")
'11/02/14 01:00:00-0500 EST'

Is this your *first* or your *second* option?  Note that this is not what
is "intended".  This is an actual Python 3.4.3 session.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150727/7173afef/attachment.html>


More information about the Python-Dev mailing list