On Tue, Aug 12, 2008 at 12:34:07PM +0100, Chris Smith wrote:
> > Unfortunately just inverting what you describe does not work. Unless you
> > use localize() pytz doesn't attempt to decide whether you're in DST or
> > not.
>
> Yes, I tried the inversion and was surprised that it didn't work. I
> can't see a good reason for it: we give it a date in one specific
> timezone and ask to convert it to another specific timezone, so why
> should it only work one way round?
It works both ways round, but you're giving it the wrong timezone, as
pytz.timezone('Europe/London')
always returns a GMT tzinfo. You have to use .localize() to get a BST
tzinfo afaict. So the datetime you construct by doing
datetime.datetime(y, m, d, h, m s,
tzinfo=pytz.timezone('Europe/London')
)
is always a GMT datetime.
I think the reason is that the datetime.datetime module contains a
fairly substantial flaw: the reference implementation assumes a tzinfo
will automatically flip onto DST. But this breaks datetime arithmetic
whenever it transitions. pytz timezones never self-adjust, so date
arithmetic is reliable.
Dan
