[Datetime-SIG] The BDFL's take
Łukasz Rekucki
lrekucki at gmail.com
Wed Jul 29 17:53:14 CEST 2015
On 29 July 2015 at 17:18, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> On Wed, Jul 29, 2015 at 10:49 AM, Lennart Regebro <regebro at gmail.com> wrote:
>> I disagree with that. To make "non-human" (ie correct) calculations I
>> have to first convert the timezone to UTC, then do the calculations,
>> then convert it back.
>
> You snipped my example and I won't repeat it for the umpteen time, but
> it did not involve converting the timezone to UTC at all.
Corrected example (with 11 as month):
>>> t = datetime(2014, 11, 1, 17, tzinfo=timezone.utc).astimezone()
>>> t.strftime('%c %Z %z')
'11/01/14 18:00:00 Central European Standard Time +0100'
>>> u = t + timedelta(1)
>>> u.astimezone().strftime('%c %Z %z')
'11/02/14 17:00:00 Central European Standard Time +0000'
The cheat here is that you call "astimezone()" without arguments, thus
it will *always* convert to UTC and back internally (even if your OS
timezone did not change a single bit). If you pass TZ explicitly, it
doesn't work:
>>> t = datetime(2014, 11, 1, 17, tzinfo=timezone.utc).astimezone()
>>> t.strftime('%c %Z %z')
'11/01/14 18:00:00 Central European Standard Time +0100'
>>> zone = t.tzinfo
>>> u = t + timedelta(1)
>>> u = u.astimezone(zone)
>>> u.strftime('%c %Z %z')
'11/02/14 18:00:00 Central European Standard Time +0100'
BR,
Łukasz Rekucki
More information about the Datetime-SIG
mailing list