On Tue, Jul 28, 2015 at 12:11 AM, Ronald Oussoren email@example.com wrote:
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. You can have just truly naive objects without DST information, and this will work just fine. I think most people's expectations are that datetime's that *are* time zone aware, should actually deal correctly with those time zones.
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. 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*. 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.