Nick Coghlan added the comment: More proposals from the thread (paraphrased):
- make any aware time() object always True (leave naive midnight as False) - make any aware time() object with a non-zero UTC offset always True (leave naive midnight and UTC midnight as False) - deprecate aware time() entirely (raises the thorny question of what to return from .time() on an aware datetime() object) - add helpers to retrieve naivemidnight and utcmidnight constants, and calculate a localmidnight value (needs to be dynamic in case the local timezone is changed) Independent observation: - if time() objects are supposed to be interpreted as representing a time difference relative to midnight rather than a structured object, why is it so hard to actually convert them to an appropriate time delta? There's no method for it, you can't just subtract midnight, there's no constructor on time delta that accepts a time object, you can't easily attach a date to the time to calculate a time delta. Use case presented for the current behaviour: - a simulation that tracks the time and date of the simulation independently and relies on the implicit bool behaviour of time objects (not stated why this is considered more maintainable than explicit comparisons with appropriate midnight objects) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13936> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
