[Python-Dev] Status on PEP-431 Timezones
R. David Murray
rdmurray at bitdance.com
Mon Jul 27 15:59:59 CEST 2015
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.
More information about the Python-Dev