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.
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.