Alexander Belopolsky <belopol...@users.sourceforge.net> added the comment:
I am having second thoughts about dst indicator. I wrote:
"""
2. Do we want to add a dst indicator and altname attributes? I would say: no. I
would rather treat DST as a different fixed offset timezone.
"""
and Brett responded:
"""
2. Keep the class dead-simple. The primary motivator is to support UTC, maybe
the %z directive for strptime. Otherwise everything else should be left out of
the stdlib and let third-parties manage it as they will be the ones that need
to manage the bazillion timezone instances they need. We don't need to dictate
an interface to them.
"""
Now note, that with fixed offset timezone class, it is possible to produce
aware local times as follows:
from datetime import datetime, timezone, timedelta
import time
EPOCH = datetime(1970, 1, 1)
def localtime(utctime=None):
if utctime is None:
tm = time.localtime()
else:
seconds = (utctime - EPOCH).total_seconds()
tm = time.localtime(seconds)
tz = (timezone(timedelta(seconds=-time.altzone), time.tzname[1])
if tm.tm_isdst else
timezone(timedelta(seconds=-time.timezone), time.tzname[0]))
return datetime(*tm[:6], tzinfo=tz)
(see also attached localtime.py)
The problem with the above implementation is that t.timetuple().tm_isdst will
always be 0 if t is produced by localtime().
I don't think adding fixed dst offset is much of complication. We already need
to override the tzinfo.dst method and if we only allow timedeltas as offset and
dst arguments to constructor, the constructor code will be extremely simple.
----------
Added file: http://bugs.python.org/file17541/localtime.py
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue5094>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
