On 26 July 2015 at 16:33, Nick Coghlan
As a user, if the apparent semantics of time zone aware date time arithmetic are accurately represented by "convert time to UTC -> perform arithmetic -> convert back to stated timezone", then I *don't care* how that is implemented internally.
This is the aspect Tim is pointing out is a change from the original design of the time zone aware arithmetic in the datetime module. I personally think its a change worth making that reflects additional decades of experience with time zone aware datetime arithmetic, but the PEP should be clear that it *is* a change.
I think the current naive semantics are useful and should not be discarded lightly. At an absolute minimum, there should be a clear, documented way to get the current semantics under any changed implementation. As an example, consider an alarm clock. I want it to go off at 7am each morning. I'd feel completely justified in writing tomorrows_alarm = todays_alarm + timedelta(days=1). If the time changes to DST overnight, I still want the alarm to go off at 7am. Even though +1 day is in this case actually + 25 (or is it 23?) hours. That's the current semantics. To be honest, I would imagine, from experience with programmers writing naive algorithms, that the current semantics is a lot less prone to error when used by such people. People forget about timezones until they are bitten by them, and if they are using the convert to UTC->calculate->convert back model, their code ends up with off-by-1-hour bugs. Certainly such mistakes can be fixed, and the people who make them educated, but I like the fact that Python's typical behaviour is to do what a non-expert would expect. By all means have the more sophisticated approach available, but if it's the default then naive users have to either (1) learn the subtleties of timezones, or (2) learn how to code naive datetime behaviour in Python before they can write their code. If the current behaviour remains the default, then *when* the naive user learns about the subtleties of timezones, they can switch to the TZ-aware datetime - but that's a single learning step, and it can be taken when the user is ready. Paul PS I don't think the above is particularly original - IIRC, it's basically Guido's argument for naive datetimes from when they were introduced. I think his example was checking his watch while on a transatlantic plane flight, but the principle is the same.