[Python-Dev] Status on PEP-431 Timezones

[Stephen J. Turnbull]

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).

Steve