Author serhiy.storchaka
Recipients belopolsky, bozo.kopic, ghaering, lemburg, serhiy.storchaka, xiang.zhang
Date 2017-01-22.06:18:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1485065903.14.0.877652726296.issue29099@psf.upfronthosting.co.za>
In-reply-to
Content
Added few minor comments on Rietveld. Technically the patch LGTM. But the behavior change of the timestamp converter for input without timezone offset perhaps needs wider discussion. We have several options:

0. Current behavior. Silently drop the timezone if there are microseconds, and raise an error when there are no microseconds. This is bad for many reasons, but some user code can depend on this.

1. Just drop the timezone, don't raise an error when there are no microseconds. The converter will become returning incorrect result instead of just failing on unexpected input. This will fix the user code that is aware of this, but currently fails when input doesn't have microseconds.

2. Return aware datetime for input with timezone offset (as in original patch). Returning aware or naive datetime depending on input can break a user code that is not prepared for this.

3. Raise an error for input with timezone offset, always return naive datetime objects from this converter. This can break the user code that depends on current behavior and works with the input containing the same timezone offsets.

Any option can break some code. I prefer option 3, but want to hear thoughts of other core developers. Maybe discuss this on Python-Dev?
History
Date User Action Args
2017-01-22 06:18:23serhiy.storchakasetrecipients: + serhiy.storchaka, lemburg, ghaering, belopolsky, xiang.zhang, bozo.kopic
2017-01-22 06:18:23serhiy.storchakasetmessageid: <1485065903.14.0.877652726296.issue29099@psf.upfronthosting.co.za>
2017-01-22 06:18:23serhiy.storchakalinkissue29099 messages
2017-01-22 06:18:22serhiy.storchakacreate