Xiang Zhang added the comment: > I think the timestamptz converter should either interpret strings without > timezone as UTC (and perhaps understand the "Z" suffix as sqlite3 date() > function) or raises an error. It should never return naive datetime.
Currently timestamptz just convert back what the user passed in, no matter naive or aware objects. What to do with them is left to the app. If we raise an error, could users use naive and aware objects together? And interpreting strings without timezone as UTC seems will mistranslate the object. For example, pass in datetime.datetime.now() and translate it back as UTC may not be right. > The timestamp converter needs better error reporting when get an input with a > timezone. I thought about it but our intention to introduce a new converter is not to break old code. Doesn't add error reporting violate the intention? Users' code may not catch the error now. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29099> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
