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 mark.dickinson
Recipients belopolsky, eric.araujo, ezio.melotti, ingo.janssen, mark.dickinson, rbp
Date 2010-11-21.20:48:52
SpamBayes Score 6.422722e-06
Marked as misclassified No
Message-id <1290372534.23.0.372628773275.issue10427@psf.upfronthosting.co.za>
In-reply-to
Content
> As you make progress on the patch, you will face more questions.

Well, if all that's wanted is for hour==24 to be legal on input, with the datetime object itself being automatically normalized at creation time, then the choices seem simple:  e.g.,

> For example, what should datetime(y, m, d, 24).date() return?  date(y,
> m, d) or date(y, m, d) + timedelta(1)?

The latter, since the two datetime objects would be indistinguishable...

> Should strptime() parse '24' as a valid %H field?

I'd say yes, provided that any minute, second or subsecond fields are all zero.

FWIW, I'm in the camp that says hour==24 should only be legal if all values for smaller time units are zero.


If a datetime object created with 'hour==24' doesn't immediately normalize itself, then I agree there are going to be a lot of hairy questions...
History
Date User Action Args
2010-11-21 20:48:54mark.dickinsonsetrecipients: + mark.dickinson, belopolsky, rbp, ezio.melotti, eric.araujo, ingo.janssen
2010-11-21 20:48:54mark.dickinsonsetmessageid: <1290372534.23.0.372628773275.issue10427@psf.upfronthosting.co.za>
2010-11-21 20:48:52mark.dickinsonlinkissue10427 messages
2010-11-21 20:48:52mark.dickinsoncreate