A real use case that I have had was with a protocol to activate a device with a daily schedule. The protocol takes start and end hours and minutes of the day. To test the device by activating it over the next few minutes, my ideal way would have taken the current time (according to the device controller) as a “time” object, and added a couple of minutes using “timedelta”. In the end I think I made my protocol API accept both “time” and “timedelta" objects, because I found “timedelta” more flexible for calculations, but the “time” class more natural in other cases.

The start and end times are local times, and daylight saving could come into play, but in reality I won’t be testing the device at 3 a.m. on a Sunday morning. If I did care, I would have to add my own logic with knowledge of the date and daylight saving, to raise an exception.

I agree with Alexander about supporting the difference between two “time” instances. The result should be a non-negative “timedelta”, at least zero, and strictly less than 24 h.