D
Damjan
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 through datetime.datetime, shouldn't change it.
Now, all is good when I use a naive datetime.datetime
-- TZ=UTC python'1341446400'
-- TZ=Asia/Tokyo python'1341446400'
But when I use an timezone aware datetime.datetime objects, the
timestamp roundtrip is destroyed. I get 2 different timestamps.
Am I missing something here, I've been reading the datetime
documentation several times, but I can't understand what is the intended
behaviour.
-- TZ=UTC pythondatetime.datetime(2012, 7, 5, 2, 0, tzinfo=<DstTzInfo 'Europe/Skopje'
CEST+2:00:00 DST>)'1341453600'
-- TZ=Asia/Tokyo pythondatetime.datetime(2012, 7, 5, 2, 0, tzinfo=<DstTzInfo 'Europe/Skopje'
CEST+2:00:00 DST>)'1341421200'
Python 2.7.3, pytz 2012c
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 through datetime.datetime, shouldn't change it.
Now, all is good when I use a naive datetime.datetime
-- TZ=UTC python'1341446400'
-- TZ=Asia/Tokyo python'1341446400'
But when I use an timezone aware datetime.datetime objects, the
timestamp roundtrip is destroyed. I get 2 different timestamps.
Am I missing something here, I've been reading the datetime
documentation several times, but I can't understand what is the intended
behaviour.
-- TZ=UTC pythondatetime.datetime(2012, 7, 5, 2, 0, tzinfo=<DstTzInfo 'Europe/Skopje'
CEST+2:00:00 DST>)'1341453600'
-- TZ=Asia/Tokyo pythondatetime.datetime(2012, 7, 5, 2, 0, tzinfo=<DstTzInfo 'Europe/Skopje'
CEST+2:00:00 DST>)'1341421200'
Python 2.7.3, pytz 2012c