[issue10427] 24:00 Hour in DateTime

[Alexander Belopolsky]

Alexander Belopolsky <belopolsky at 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:

def normdatetime(Y, M, D, h, m, s):
    return datetime(Y, M, D) + timedelta(hours=h, minutes=m, seconds=s)

It would be much more interesting to allow datetime objects to store ISO 8601 data without loss of information.  It may be important to some applications that datetime(Y, M, D, 24).date() is date(Y, M, D) rather than the next day.  Other applications may want to distinguish between datetime(Y, M, D, 24) and datetime(Y, M, D) + timedelta(1) in some other ways.  For leap seconds accounting, normalizing ISO 8601 timestamps with seconds=60 to the next minute is certainly wrong.  An application that is unfortunate enough to record data during a leap second would clearly want to distinguish that data from data recorded a second later.

I believe that from practical applications point of view, it would be best to allow storing hour=24 and second=60 in datetime structure and order the resulting objects in the same way as ISO 8601 strings are ordered alphabetically.  In other words, 

Y-M-D 24:00 < Y-M-D+1 00:00

and

Y-M-D 23:59:60 < Y-M-D+1 00:00:00.

There is no sane choice for subtraction operation involving these special values or for adding timedeltas to them.  It is probably best to raise an exception in those cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10427>
_______________________________________