Message121980
| Author |
belopolsky |
| Recipients |
belopolsky, eric.araujo, ezio.melotti, ingo.janssen, rbp |
| Date |
2010年11月21日.20:29:06 |
| SpamBayes Score |
2.275473e-08 |
| Marked as misclassified |
No |
| Message-id |
<AANLkTikU_qx8c5n5s2RRrEqFqTrWL7TNQQaqraoU-6jA@mail.gmail.com> |
| In-reply-to |
<1290363882.13.0.672986752312.issue10427@psf.upfronthosting.co.za> |
| Content |
On Sun, Nov 21, 2010 at 1:24 PM, Rodrigo Bernardo Pimentel
<report@bugs.python.org> wrote:
..
> I was writing tests for this issue, when something struck me: ok, datetime(year, month, day, 24) is valid.
> But is datetime(year, month, day, 24, 1) valid? Or datetime(year, month, day, 24, 0, 0, 1)?
>
As you make progress on the patch, you will face more questions. For
example, what should datetime(y, m, d, 24).date() return? date(y, m,
d) or date(y, m, d) + timedelta(1)? Should strptime() parse '24' as a
valid %H field? Similarly, should strftime() produce '24'? Is
datetime(y, m, d, 24) equal to datetime(y, m, d) + timedelta(1)? If
so, hash calculation should be special cased.
On your original question, I feel that hour=24 should be allowed
regardless of the other values. I would recommend, however, that you
review python-dev discussion about allowing second=60 (search for
"leap second"). Once you have a reference implementation you will
need to explain motivations behind your choices on python-dev. |
|