[Python-Dev] Status on PEP-431 Timezones

[Tim Peters]

[Ronald Oussoren]
>> I totally agree with that, having worked on applications
> that had to deal with time a lot and including some where the
> end of a day was at 4am the following day.  That app never
> had to deal with DST because not only are the transitions at
> night, the are also during the weekend.

[Lennart Regebro]
> If you don't have to deal with DST, then you don't have to have
> tzinfo's in your date objects.

There are no tzinfos on date objects.  I assume Ronald is talking
about datetime objects.

> You can have just truly naive objects without DST information,
> and this will work just fine.

I suspect not at all:  Ronald pretty obviously wants to mirror the
local clock, he just doesn't care about what happens in the tiny
number of cases adjacent to a DST transition buondary, because those
boundaries occur "at night ... during the weekend", times his app
predictably never needed to worry about.

> I think most people's expectations are that datetime's that *are* time
> zone aware, should actually deal correctly with those time zones.

They "almost always" do, you know ;-)  You want perfection in every
case.  Others are delighted to trade off perfection in "twice a year
wee hour on a weekend" cases for straightforward "move N units in
local time" local-time arithmetic

>> It might be nice to have time zone aware datetime objects with the right(TM) semantics, but
>> those can and should not replace the naive objects we know and love.

> Yes, they most certainly should.

They can't, at least not before Python 4.  Nobody can break over a
decade's worth of user code for something so objectively minor.  Even
in Python 4, you'd still need to get Guido's approval to reject his
design, and I doubt he'd be willing (but, of course, I may be wrong
about that).

There are other, backward-compatible, ways to get what you want
(although I don't really see a need:  it's a one-line Python function
for each kind of tz-perfection-in-all-cases arithmetic you favor).
For example, I offhandedly suggested adding a new magic attribute to
tzinfo objects; if present, datetime would compute "the other" kind of
arithmetic.  Another idea I saw last night was to create a new
timedelta-like class, then change datetime's arithmetic to act
differently when asked to use an instance of that new class in
arithmetic (although, unlike the magic tzinfo attribute, that couldn't
affect the behavior of datetime-datetime subtraction).

> I will try to shut up now, but let me be clear on that the time zone
> support as it stands now is intentionally broken. Not naive, *broken*.

It does indeed intentionally deviate from reality in some cases.

> All the usecases people have here for supporting "naive" objects would
> work just as well if they actually used naive objects, ie datetimes
> with no timezone info. If you explicitly do NOT want the
> datetimeobject to care about timezones, then you should not add a
> timezone to the object.

As at the start, I'm sure Ronald does/did care about mirroring local
time, including DST.  He just doesn't care about what happens at the
relative handful of "problem times".

Lots of apps are similar.  Someone yesterday asked for an example of
_how_ he could code a cross-timezone app to schedule remote meetings
with his students.  They need to occur at the same local time (for the
student) once per week, and he wanted a 5-minute (something like that)
warning before the meeting started in his own time zone.  I'm not sure
whether anyone answered him yet.

This is almost certainly another case where nobody cares what happens
_near_ DST transition boundaries (these are humans, so neither side
would agree to meet routinely at wee hours on a weekend).  So it's all
easy to do with Python as it exists:  "naive arithmetic" is exactly
what he needs to schedule a series of meetings at the same local times
separated by (naive) local weeks.

    first_meeting_time = datetime(Y, M, D, H, tzinfo=student_timezone)
    student_times = [first_meeting_time + timedelta(weeks=i) for i in
range(NUM_MEETINGS)]
    my_times = [student_time.astimezone(my_timezone) for student_time
in student_times]

DST transitions are vital to track on both sides, but no time in use
will appear near a transition boundary - "naive time" is a perfectly
adequate approximation, because it agrees with reality at every time
the app cares about.  And "naive datetime arithmetic" is the only kind
of arithmetic of use here.