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 gwrtheyrn
Recipients Lakin.Wecker, belopolsky, eric.araujo, georg.brandl, gwrtheyrn, lemburg, r.david.murray, tim.peters
Date 2012-11-27.14:10:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1354025411.59.0.671149248194.issue13936@psf.upfronthosting.co.za>
In-reply-to
Content
I disagree, I think this bug should be reopened and fixed.

A use case that I just ran into: I'm using a Django form with time fields that aren't required, but that are only valid in combination (if there's a open time there has to be a close time).

    if not (self.closed or (self.open_time and self.close_time )):                  
        raise ValidationError("Invalid times")

This leads to a Validation Error when using the times 12:00 and 00:00.

Of course, this case is debatable and can be worked around by using `self.open is not None and self.close is not None`, but there are even more problems when using the times inside the template.

I'm using the following widespread pattern inside my templates:

    <p>Close time: {{ close_time|default:"-" }}</p>

The "default" filter used in this case displays the string "-" if the value on the left side of the | symbol evaluates to False. That makes sense in almost all of the cases.

In the case of the `datetime.time(0, 0)` object, the default value is displayed, even though `datetime.time(0, 0).__str__()` results in a valid string (in this case '00:00:00').

(By the way, through these experiments I also found a bug in Django's date formatting template function caused by this inconsistency, which I will report separately.)

I agree that casting time objects to a boolean value doesn't make much sense. But especially because of that, inconsistencies in the resulting boolean value should NOT exist. Yet another argument for this is that in many regions midnight isn't considered 00:00, but 24:00, which would obviously not evaluate to False.

Please fix this. Otherwise it will lead to a whole lot of weird bugs in software using the datetime library.
History
Date User Action Args
2012-11-27 14:10:11gwrtheyrnsetrecipients: + gwrtheyrn, lemburg, tim.peters, georg.brandl, belopolsky, eric.araujo, r.david.murray, Lakin.Wecker
2012-11-27 14:10:11gwrtheyrnsetmessageid: <1354025411.59.0.671149248194.issue13936@psf.upfronthosting.co.za>
2012-11-27 14:10:11gwrtheyrnlinkissue13936 messages
2012-11-27 14:10:10gwrtheyrncreate