Alexander Belopolsky <alexander.belopol...@gmail.com> added the comment:

On Mon, Jun 11, 2012 at 11:18 PM, James Henstridge <rep...@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.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue9527>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to