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 skip.montanaro
Recipients Amber.Yust, Andreas.Pelme, Hanxue.Lee, Lakin.Wecker, alex, belopolsky, cvrebert, dstufft, eric.araujo, ethan.furman, georg.brandl, gwrtheyrn, lemburg, ncoghlan, pitrou, r.david.murray, shai, skip.montanaro, tim.peters, yselivanov
Date 2014-03-07.13:19:21
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1394198362.0.0.893392430588.issue13936@psf.upfronthosting.co.za>
In-reply-to
Content
> the current behaviour takes something that would be a harmless style error for most structured data types ...

I'm not sure what a "structured data type" is, but in my mind the original poster's construct is more than a style error. He was using None as a sentinel, but not explicitly testing for its presence. The same error would be present if he used None as a sentinel value where the range of possible values was the set of all integers.

If there are problems with the definition of "false time" such that there are some combinations of time and timezone where UTC midnight is not zero, I would prefer to correct them.

Further, playing the devil's advocate, if you dispense with any false elements of time objects, why not simply zero out the nb_nonzero slot in time_as_number? Once that's gone, the time_as_number structure is all zeros, so the tp_as_number slot in PyDateTime_TimeType can be cleared.
History
Date User Action Args
2014-03-07 13:19:22skip.montanarosetrecipients: + skip.montanaro, lemburg, tim.peters, georg.brandl, ncoghlan, belopolsky, pitrou, eric.araujo, alex, r.david.murray, cvrebert, ethan.furman, gwrtheyrn, Lakin.Wecker, yselivanov, shai, dstufft, Andreas.Pelme, Amber.Yust, Hanxue.Lee
2014-03-07 13:19:21skip.montanarosetmessageid: <1394198362.0.0.893392430588.issue13936@psf.upfronthosting.co.za>
2014-03-07 13:19:21skip.montanarolinkissue13936 messages
2014-03-07 13:19:21skip.montanarocreate