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 lemburg
Recipients akira, belopolsky, doughellmann, lemburg, vstinner
Date 2015-05-27.09:12:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1432717940.06.0.148867122247.issue23574@psf.upfronthosting.co.za>
In-reply-to
Content
Here's what mxDateTime uses:

>>> import mx.DateTime
>>>
>>> t1 = mx.DateTime.DateTime(2012,6,30,23,59,60)
>>> t2 = mx.DateTime.DateTime(2012,7,1,0,0,0)
>>>
>>> t1
<mx.DateTime.DateTime object for '2012-06-30 23:59:60.00' at 7fbb36008d68>
>>> t2
<mx.DateTime.DateTime object for '2012-07-01 00:00:00.00' at 7fbb36008d20>
>>>
>>> t2-t1
<mx.DateTime.DateTimeDelta object for '00:00:00.00' at 7fbb35ff0540>
>>> (t2-t1).seconds
0.0
>>>
>>> t1 + mx.DateTime.oneSecond
<mx.DateTime.DateTime object for '2012-07-01 00:00:01.00' at 7fbb360083d8>

It preserves the broken down values, but uses POSIX days of 86400 seconds per day to calculate time deltas.

It's a compromise, not a perfect solution, but it prevents applications from failing for that one second every now and then.

I don't believe there is a perfect solution, since what your application or users expect may well be different. All I can say is that raising exceptions in these rare cases is not what your users typically want :-)
History
Date User Action Args
2015-05-27 09:12:20lemburgsetrecipients: + lemburg, belopolsky, vstinner, doughellmann, akira
2015-05-27 09:12:20lemburgsetmessageid: <1432717940.06.0.148867122247.issue23574@psf.upfronthosting.co.za>
2015-05-27 09:12:19lemburglinkissue23574 messages
2015-05-27 09:12:19lemburgcreate