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.y
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 dateti
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)
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)
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')
fr
I've been struggling with an app that uses
Postgresql/Psycopg2/SQLAlchemy and I've come to this confusing
behaviour of datetime.datetime.
First of all, the "Seconds since Epoch" timestamps are always in UTC, so
shouldn't change with timezones. So I'd expect that a round trip of a
timestamp
