[M.-A. Lemburg]
... Perhaps Tim just wanted to be able to make float(time(0,0,0)) return 0.0 seconds some day. That's what mxDateTime does for time values.
Now you're getting close :-) There was an endless list of features various people said they wanted in a datetime module. At the time, we picked a large subset we could do in time, and released it. There was every expectation that more features may be added later. Among them were various kinds of conversions and various kinds of arithmetic enhancements. For example, modular arithmetic on time objects was a possibility. In that case, time(0, 0, 0) would become "a zero value" just as much as 0 or 0.0 or 0j or 0x00 are zero values. But if it weren't _treated_ as "a zero value" from the start, backward compatibility would prevent it from being treated as a zero value for the first time later. So, what the heck - like all other zero/empty objects, time(0, 0, 0) was fiddled to evaluate to False in a Boolean context, AND (something nobody seems to have noticed yet) plain time() was fiddled to return it:
bool(int()) is bool(complex()) is bool(float()) is bool(datetime.time()) True
People can say that "midnight" isn't a compelling "sentinel value", and I agree about the "compelling" part, but in all implementation respects it does _act_ as "a sentinel value". If people don't want to use it as one, fine, that's their choice. I've used it as one, and it works fine for that purpose. As things turned out, nobody seemed to care much about modular (are any other kind of) arithmetic on time objects after all. Nevertheless, we went about 9 years before anyone complained about the code added to support the _possibility_ for doing that cleanly. The "seconds from midnight" view was also in play, with a view toward clean conversions to float-ish types.