Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
resolution: - rejected
stage: test needed - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10427
Changes by Chris Rebert pyb...@rebertia.com:
--
nosy: +cvrebert
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10427
___
___
Python-bugs-list
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Is there still interest in pursuing this? Normalizing out of bounds arguments
to datetime constructor is easy, but rather pointless. It is trivial to
implement this functionality using existing timedelta constructor:
Rodrigo Bernardo Pimentel r...@isnomore.net added the comment:
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)?
I would say those aren't valid,
ingo janssen ingoo...@gmail.com added the comment:
On Sun, Nov 21, 2010 at 7:24 PM, Rodrigo Bernardo Pimentel wrote:
I would say those aren't valid, although that makes checking forvalid hour
values slightly weird
(as in not straightforward): 24 is valid if minutes, seconds and microseconds
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Sun, Nov 21, 2010 at 1:24 PM, Rodrigo Bernardo Pimentel
rep...@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
Mark Dickinson dicki...@gmail.com added the comment:
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
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Sun, Nov 21, 2010 at 3:48 PM, Mark Dickinson rep...@bugs.python.org wrote:
..
Well, if all that's wanted is for hour==24 to be legal on input, with the
datetime object
itself being automatically normalized at
Mark Dickinson dicki...@gmail.com added the comment:
What about time objects? If we take the normalized at creation time
approach, time(24) may still be disallowed.
Yes, I guess that would follow. That wouldn't bother me too much. :-)
--
___
New submission from ingo janssen ingoo...@gmail.com:
Short:
make the DateTime class and related also accept 24 for the hour instead of
stopping at 23:59:59.
from the python doc:
class datetime.datetime(year, month, day[, hour[, minute[, second[,
microsecond[, tzinfo])
The year, month and
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
components: +Library (Lib)
nosy: +belopolsky, ezio.melotti
versions: -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2
___
Python tracker rep...@bugs.python.org
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
+1
Note that in Python, semi-open intervals are favored, but specifying the last
hour of the day is awkward when using datetime (as OP mentioned) and impossible
using just time. Using closed intervals is not a good
Changes by Éric Araujo mer...@netwok.org:
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10427
___
___
Python-bugs-list
13 matches
Mail list logo
