This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author xiang.zhang
Recipients belopolsky, bozo.kopic, ghaering, lemburg, serhiy.storchaka, xiang.zhang
Date 2017-01-12.06:24:38
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1484202279.09.0.469584625318.issue29099@psf.upfronthosting.co.za>
In-reply-to
Content
> 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.
History
Date User Action Args
2017-01-12 06:24:39xiang.zhangsetrecipients: + xiang.zhang, lemburg, ghaering, belopolsky, serhiy.storchaka, bozo.kopic
2017-01-12 06:24:39xiang.zhangsetmessageid: <1484202279.09.0.469584625318.issue29099@psf.upfronthosting.co.za>
2017-01-12 06:24:39xiang.zhanglinkissue29099 messages
2017-01-12 06:24:38xiang.zhangcreate