[Python-Dev] Status on PEP-431 Timezones

[R. David Murray]

On Mon, 27 Jul 2015 02:09:19 -0500, Tim Peters <tim.peters at gmail.com> wrote:
> 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.

I *think* I'd be happy with that solution.

I'm not sure if the opinion of a relatively inexperienced timezone user
(whose head hurts when thinking about these things) is relevant, but in
case it is:

My brief experience with pytz is that it gets this all "wrong".  (Wrong
is in quotes because it isn't wrong, it just doesn't match my use
cases).  If I add a timedelta to a pytz datetime that crosses the DST
boundary, IIRC I get something that still claims it is in the previous
"timezone" (which it therefore seemed to me was really a UTC offset),
and I have to call 'normalize' to get it to be in the correct "timezone"
(UTC offset).  I don't remember what that does to the time, and I have
no intuition about it (I just want it to do the naive arithmetic!)

This makes no sense to me, since I thought a tzinfo object was supposed
to represent the timezone including the DST transitions.  I presume this
comes from the fact that datetime does naive arithmetic and pytz is
trying to paste non-naive arithmetic on top?

So, would it be possible to take the timezone database support from
pytz, and continue to implement naive-single-zone arithmetic the way Tim
proposes, and have it automatically produce the correct UTC offset and
UTC-offset-label afterward, without a normalize call?  I assumed that
was what the PEP was proposing, but I never read it so I can't complain
that I was wrong :)

I have a feeling that I'm completely misunderstanding things, since
tzinfo is still a bit of a mystery to me.

Based on this discussion it seems to me that (1) datetime has to/should
continue to do naive arithmetic and (2) if you need to do non-naive UTC
based calculations (or conversions between timezones) you should be
converting to UTC *anyway* (explicit is better than implicit).  The
addition of the timezone DB would then give us the information to *add*
tools that do conversions between time zones &c.

At Tim says, the issue of disambiguation is separate, and I seem to
recall a couple of proposals from the last time this thread went around
for dealing with that.

--David