Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #24948 > unrolled thread

Re: Confusing datetime.datetime

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Confusing datetime.datetime Damjan <gdamjan@gmail.com> - 2012-07-06 00:55 +0200
    Re: Confusing datetime.datetime Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-06 01:28 +0000
      Re: Confusing datetime.datetime Damjan <gdamjan@gmail.com> - 2012-07-06 04:05 +0200
    Re: Confusing datetime.datetime Hans Mulder <hansmu@xs4all.nl> - 2012-07-06 18:41 +0200
      Re: Confusing datetime.datetime Damjan <gdamjan@gmail.com> - 2012-07-08 23:49 +0200

#24948 — Re: Confusing datetime.datetime

On 05.07.2012 16:10, Damjan wrote:
> I've been struggling with an app that uses
> Postgresql/Psycopg2/SQLAlchemy  and I've come to this confusing
> behaviour of datetime.datetime.


Also this:

#! /usr/bin/python2
# retardations in python's datetime

import pytz
TZ = pytz.timezone('Europe/Skopje')

from datetime import datetime

x1 = datetime.now(tz=TZ)
x2 = datetime(x1.year, x1.month, x1.day, tzinfo=TZ)

assert x1.tzinfo == x2.tzinfo


WHY does the assert throw an error???

[toc] | [next] | [standalone]

#24949

On Fri, 06 Jul 2012 00:55:48 +0200, Damjan wrote:

> Also this:
> 
> #! /usr/bin/python2
> # retardations in python's datetime
> 
> import pytz
> TZ = pytz.timezone('Europe/Skopje')
>
> from datetime import datetime
> 
> x1 = datetime.now(tz=TZ)
> x2 = datetime(x1.year, x1.month, x1.day, tzinfo=TZ)
> 
> assert x1.tzinfo == x2.tzinfo
> 
> 
> WHY does the assert throw an error???

I don't have pytz, so I can't test your exact code. But using my own time 
zone class, it seems to work fine in Python 2.5, 2.6 and 2.7:

from datetime import datetime, timedelta, tzinfo
ZERO = timedelta(0)
HOUR = timedelta(hours=1)

class UTC(tzinfo):
    def utcoffset(self, dt):
        return ZERO
    def tzname(self, dt):
        return "UTC"
    def dst(self, dt):
        return ZERO

utc = UTC()
t1 = datetime.now(tz=utc)
t2 = datetime(t1.year, t1.month, t1.day, tzinfo=utc)
assert t1.tzinfo == t2.tzinfo


No assertion error at all.

This makes me think that the "retardation" as you put it is not in 
Python's datetime module at all, but in pytz.

What does TZ == TZ give? If it returns False, I recommend you report it 
as a bug against the pytz module.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#24951

> from datetime import datetime, timedelta, tzinfo
> ZERO = timedelta(0)
> HOUR = timedelta(hours=1)
>
> class UTC(tzinfo):
>      def utcoffset(self, dt):
>          return ZERO
>      def tzname(self, dt):
>          return "UTC"
>      def dst(self, dt):
>          return ZERO
>
> utc = UTC()
> t1 = datetime.now(tz=utc)
> t2 = datetime(t1.year, t1.month, t1.day, tzinfo=utc)
> assert t1.tzinfo == t2.tzinfo
>
>
> No assertion error at all.
>
> This makes me think that the "retardation" as you put it is not in
> Python's datetime module at all, but in pytz.
>
> What does TZ == TZ give? If it returns False, I recommend you report it
> as a bug against the pytz module.

It returns True, so it seems to be changed in the datetime object??

I tried both 2.7 and 3.2

-- 
damjan

[toc] | [prev] | [next] | [standalone]

#24976

On 6/07/12 00:55:48, Damjan wrote:
> On 05.07.2012 16:10, Damjan wrote:
>> I've been struggling with an app that uses
>> Postgresql/Psycopg2/SQLAlchemy  and I've come to this confusing
>> behaviour of datetime.datetime.
> 
> 
> Also this:
> 
> #! /usr/bin/python2
> # retardations in python's datetime
> 
> import pytz
> TZ = pytz.timezone('Europe/Skopje')
> 
> from datetime import datetime
> 
> x1 = datetime.now(tz=TZ)
> x2 = datetime(x1.year, x1.month, x1.day, tzinfo=TZ)
> 
> assert x1.tzinfo == x2.tzinfo
> 
> WHY does the assert throw an error???

Because x1 and x2 have different time zones.

The tzinfo field in x2 is equal to TZ and has a UTC offset of 1 hour.
The tzinfo field in x1 contains the DST version of that timezone,
with a UTC offset of 2 hours, because Skopje is currently on DST.

I think you want:

x2 = TZ.localize(datetime(x1.year, x1.month, x1.day))

That produces a datetime with the year, month and day set as indicated
and tzinfo set to the correct UTC offset for that date, at 00:00 hours.

Or maybe you need:

x2 = TZ.localize(datetime(x1.year, x1.month, x1.day, 12))
x2 = x2.replace(hour=0)

That determines whether DST should be on at noon, and then resets the
hour field to zero.  This produces the same outcome as the one liner,
except on days when DST is switched on or off.


Hope this helps,

-- HansM

[toc] | [prev] | [next] | [standalone]

#25054

> Because x1 and x2 have different time zones.
>
> The tzinfo field in x2 is equal to TZ and has a UTC offset of 1 hour.
> The tzinfo field in x1 contains the DST version of that timezone,
> with a UTC offset of 2 hours, because Skopje is currently on DST.
>
> I think you want:
>
> x2 = TZ.localize(datetime(x1.year, x1.month, x1.day))
>
> That produces a datetime with the year, month and day set as indicated
> and tzinfo set to the correct UTC offset for that date, at 00:00 hours.
>
> Or maybe you need:
>
> x2 = TZ.localize(datetime(x1.year, x1.month, x1.day, 12))
> x2 = x2.replace(hour=0)
>
> That determines whether DST should be on at noon, and then resets the
> hour field to zero.  This produces the same outcome as the one liner,
> except on days when DST is switched on or off.


Thanks, I think this will help me.

Although these issues seem very much underdocumented in the datetime 
documentation. Are there any good references of using good times in Python?



-- 
damjan

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web