homepage

> 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.