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