[Python-Dev] Status on PEP-431 Timezones

[Lennart Regebro]

On Mon, Jul 27, 2015 at 3:59 PM, R. David Murray <rdmurray at bitdance.com> wrote:
> 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).

Right.

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

But what is it that you expect?

That you add one hour to it, and the datetime moves forward one hour
in actual time? That's doable, but during certain circumstance this
may mean that you go from 1AM to 1AM, or from 1AM to 3AM.

Or do you expect that adding one hour will increase the hour count
with one, ie that the "wall time" increases with one hour? This may
actually leave you with a datetime that does not exist, so that is not
something you can consistently do.

Dates and times are tricky, and especially with DST it is simply
possible to make an implementation that is intuitive in all cases to
those who don't know about the problems. What we should aim for is an
implementation that is easy to understand and hard to make errors
with.

> 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?

Exactly.

> 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?

That depends on your definition of "correct".

//Lennart