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 belopolsky
Recipients belopolsky, eric.araujo, ezio.melotti, ingo.janssen, mark.dickinson, rbp
Date 2011-04-08.01:06:02
SpamBayes Score 3.26381e-08
Marked as misclassified No
Message-id <1302224764.41.0.315169021611.issue10427@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2011-04-08 01:06:04belopolskysetrecipients: + belopolsky, mark.dickinson, rbp, ezio.melotti, eric.araujo, ingo.janssen
2011-04-08 01:06:04belopolskysetmessageid: <1302224764.41.0.315169021611.issue10427@psf.upfronthosting.co.za>
2011-04-08 01:06:03belopolskylinkissue10427 messages
2011-04-08 01:06:02belopolskycreate