Message 308569 - Python tracker

➜

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.

In-reply-to
Author	p-ganssle
Recipients	Anders.Hovmöller, Arfrever, Elvis.Pranskevichus, Eric.Hanchrow, Roman.Evstifeev, SilentGhost, aymeric.augustin, barry, belopolsky, berker.peksag, cben, cvrebert, davydov, deronnax, eric.araujo, flying sheep, jcea, jstasiak, jwilk, karlcow, kirpit, larsonreever, martin.panter, mcepl, mihaic, nagle, ncoghlan, p-ganssle, pbryan, perey, piotr.dobrogost, r.david.murray, roysmith, sirex, vstinner
Date	2017年12月18日.14:59:52
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<1513609192.6.0.213398074469.issue15873@psf.upfronthosting.co.za>

Content
> Not if the time is associated with a particular day. Imagine implementing datetime.fromisoformat by separately calling date.fromisoformat and time.fromisoformat. The date will be off by one day if you naively rounded 2017年12月18日 23:59 "up" to 2017年12月18日 00:00. Yes, I suppose this is a problem if you implement it that way. Seems like a somewhat moot point, but I think any decision about rounding should probably be driven by what people are expecting more than by how it is implemented. That said, I can see a good case for truncation and rounding up for something like '2016-12-31T23:59:59.999999999'. Rounding up to '2017-01-01' is certainly the closest whole millisecond to round to, but often people expressing a "23:59:59.9999999" are trying to actually express "the last possible moment before 00:00".

Content

> Not if the time is associated with a particular day. Imagine implementing datetime.fromisoformat by separately calling date.fromisoformat and time.fromisoformat. The date will be off by one day if you naively rounded 2017年12月18日 23:59 "up" to 2017年12月18日 00:00.
Yes, I suppose this is a problem if you implement it that way. Seems like a somewhat moot point, but I think any decision about rounding should probably be driven by what people are expecting more than by how it is implemented.
That said, I can see a good case for truncation *and* rounding up for something like '2016-12-31T23:59:59.999999999'. Rounding up to '2017-01-01' is certainly the closest whole millisecond to round to, *but* often people expressing a "23:59:59.9999999" are trying to actually express "the last possible moment *before* 00:00".

History
Date	User	Action	Args
2017年12月18日 14:59:52	p-ganssle	set	recipients: + p-ganssle, barry, jcea, cben, roysmith, ncoghlan, belopolsky, nagle, vstinner, jwilk, mcepl, eric.araujo, Arfrever, r.david.murray, davydov, cvrebert, karlcow, SilentGhost, Elvis.Pranskevichus, perey, flying sheep, mihaic, aymeric.augustin, Roman.Evstifeev, berker.peksag, martin.panter, piotr.dobrogost, kirpit, Anders.Hovmöller, jstasiak, Eric.Hanchrow, deronnax, pbryan, sirex, larsonreever
2017年12月18日 14:59:52	p-ganssle	set	messageid: <1513609192.6.0.213398074469.issue15873@psf.upfronthosting.co.za>
2017年12月18日 14:59:52	p-ganssle	link	issue15873 messages
2017年12月18日 14:59:52	p-ganssle	create

homepage