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 <[email protected]>
<http://bugs.python.org/issue12750>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
