Tres Seaver writes:
- From a human's perspective, "a day from now" is always potentially
unambigous, just like "a month from now" or "a year from now", whereas "24 hours from now" is never so.
I gather you've never been a prof who told a student with aggravated "writer's block" she had 24 hours to produce a draft, and have her walk in 45 minutes early, apologizing profusely for being 15 minutes late!
Humans always have a use case in mind. In *my* mind, I *meant* 24 hours or 84600 seconds (estimating process allocations of 2 hours inadvertant sleeping, 3 hours writing, and 19 hours fussing and/or panicking ;-), while the *student* *interpreted* it as "be here with a stack of paper at the same time tomorrow".
You can say "that's just wordplay" (or more precisely, "that's a communication problem"). AFAICS, one way to view Tim's point (or Guido's point in the original decision) is that it's *always* a communication problem, and that Python should refuse to guess. Since communicating sufficiently accurate information about the mapping from any local time to time in any civil system is always difficult (and impossible in the case of civil times one legislative session or more in the future), Python chose naive time arithmetic and naive time classes to represent it (FVO "naive" equivalent to "what Tim said").
In other words, datetime and timedelta implement the only calculations it was feasible to "just get it right" at the time (and I would say that because of the communication problem the alternative use case is *still* an application problem, not a library problem).