On Mon, Jun 11, 2012 at 11:18 PM, James Henstridge <report@bugs.python.org> wrote:
> One problem I can see with using a fixed offset
> tzinfo for localtime is that it might confuse people
> when doing date arithmetic.

Yes, this is the issue that I discussed in my first python-ideas/python-dev post.  (See msg162631 above.)

>    >>> d = datetime.localtime() + timedelta(days=7)
>
> While it will give a correct answer as a point in time it
> will have the wrong time zone offset if run just before a
> daylight saving transition, which could be just as confusing.

I think my latest proposal will fare slightly better in this scenario.  I am now propose implementing local timezone info discovery in datetime.astimezone() method.  Obtaining local time will now be a little more verbose:

local_time = datetime.now(timezone.utc).astimezone()

but (local_time + timedelta(7)).astimezone() will give you correctly adjusted aware datetime seven days later.

If we also implement astimezone() for naive instances, we can even support naive local time arithmetics:  (datetime.now() + timedelta(7)).astimezone() will produce the same time of day as "now" unless it falls into a non-existing hour.

> I'm not sure how you'd solve this without e.g. importing
> pytz into the standard library though.

Importing pytz will not help.  Pytz fudges the issue by extending tzinfo methods to accept isdst flag, but there is no place in datetime to store this flag.  Doing time calculations in local time is inherently ambiguous in presence of DST.  On the other hand, producing tz aware local time from any unambiguous absolute time specification (UTC, time_t, local time + tz offset, etc.) is a well-defined problem which does not have an adequate solution.