[Tres Seaver
"Naive" alarm clocks (those which don't know from timezones) break human expectations twice a year, because their users have to be awake to fix them (or make the clock itself out-of-whack with real civil time for the hours between fixing and the actual transition). For confirmatoin, ask your local priest / pastor about the twice yearly mixups among congregants whose clocks don't self-adjust for the DST boundary: some show up late / early for church *every* time the local zone changes.
Sure. I don't see how this applies to Python's arithmetic, though. For a start, you're talking about alarm clocks ;-) Note that "naive" is a technical term in the datetime context, used all over the datetime docs. However, I'm using "naive arithmetic" as a shorthand for what would otherwise be a wall of text. That's my own usage; the docs only apply "naive" and "aware" to date, time and datetime objects (not to operations on such objects).
I'd be in favor of dropping "days" from timedelta, myself, for just this reason: if "1 day" is the same for your usecase as "24 hours", then just do the math yourself.
timedelta objects only store days, seconds, and microseconds, which is advertised. It would be bizarre not to allow to set them directly. They're the only timedelta components for which instance attributes exist. In the timedelta constructor, it's the seconds, milliseconds, minutes, hours, and weeks arguments that exist solely for convenience. You could "do the math yourself" for all those too - but why would you want to make anyone do that for any of them? All the world's alarm clocks would remain just as broken regardless ;-) Even if days weren't a distinguished unit for timedelta, I'd still much rather write, e.g., timedelta(days=5, hours=3) than timedelta(hours=123) or timedelta(hours=5*24 + 3) etc. The intent of the first spelling is obvious at a glance.