On Mon, 27 Jul 2015 02:09:19 -0500, Tim Peters <tim.pet...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com