akira added the comment: > I suspect that in the absence of %z, the most useful option would be to > return naive datetime in the local timezone, but that can be added later.
Naive datetime in the local timezone may lose information that is contained in the input timestamp: >>> import os >>> import time >>> from datetime import datetime >>> import pytz >>> os.environ['TZ'] = ':America/New_York' >>> time.tzset() >>> naive_dt = datetime(2014, 11, 2, 1, 30) >>> naive_dt.timestamp() 1414906200.0 >>> naive_dt.strftime('%s') '1414906200' >>> pytz.timezone('America/New_York').localize(naive_dt, is_dst=False).timestamp() 1414909800.0 >>> pytz.timezone('America/New_York').localize(naive_dt, is_dst=True).timestamp() 1414906200.0 >>> pytz.timezone('America/New_York').localize(naive_dt, is_dst=None) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "~/.virtualenvs/py3.4/lib/python3.4/site-packages/pytz/tzinfo.py", line 349, in localize raise AmbiguousTimeError(dt) pytz.exceptions.AmbiguousTimeError: 2014-11-02 01:30:00 1414906200 timestamp corresponds to 2014-11-02 01:30:00-04:00 but datetime(2014, 11, 2, 1, 30) along is ambiguous -- it may correspond to both 1414906200 and 1414909800 if local timezone is America/New_York. It would be nice if datetime.strptime() would allow the round-trip whatever the local timezone is: >>> ts = '1414906800' >>> datetime.strptime(ts, '%s').strftime('%s') == ts it is possible if strptime() returns timezone-aware datetime object. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12750> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com