On Mon, 27 Jul 2015 02:09:19 -0500, Tim Peters
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