[Python-Dev] Status on PEP-431 Timezones

[Tim Peters]

[Paul Moore <p.f.moore at gmail.com>]
>> ....
>> As an example, consider an alarm clock. I want it to go off at 7am
>> each morning. I'd feel completely justified in writing
>> tomorrows_alarm = todays_alarm + timedelta(days=1).

[Lennart Regebro <regebro at gmail.com>]
> That's a calendar operation made with a timedelta.

It's an instance of single-timezone datetime arithmetic, of the
datetime + timedelta form.  Your examples have been of the same form.
Note that after Paul's

     tomorrows_alarm = todays_alarm + timedelta(days=1)

it's guaranteed that

    assert tomorrows_alarm - todays_alarm == timedelta(days=1)

will succeed too.

> The "days" attribute here is indeed confusing as it doesn't mean 1 day,
> it means 24 hours.

Which, in naive arithmetic, are exactly the same thing.  That's
essentially why naive arithmetic is the default:  it doesn't insist on
telling people that everything they know is wrong ;-)  There's nothing
confusing about Paul's example _provided that_ single-timezone
arithmetic is naive.  It works exactly as he intends every time, and
obviously so.

Seriously, try this exercise:  how would you code Paul's example if
"your kind" of arithmetic were in use instead?  For a start, you have
no idea in advance how many hours you may need to add to get to "the
same local time tomorrow".  24 won't always work  Indeed, no _whole_
number of hours may work (according to one source I found, Australia's
Lord Howe Island uses a 30-minute DST adjustment).  So maybe you don't
want to do it by addition.  What then?  Pick apart the year, month and
day components, then simulate "naive arithmetic" by hand?

The point is that there's no _obvious_ way to do it then.  I'd
personally strip off the tzinfo member, leaving a wholly naive
datetime where arithmetic "works correctly" ;-) , add the day, then
attach the original tzinfo member again.

But for a dozen years it's sufficed to do what Paul did.