On Wed, 29 Jul 2015 06:26:44 +0200, Lennart Regebro firstname.lastname@example.org wrote:
On Tue, Jul 28, 2015 at 10:26 PM, Tim Peters email@example.com wrote:
I have yet to see a use case for that.
Of course you have. When you address them, you usually dismiss them as "calendar operations" (IIRC).
Those are not usecases for this broken behaviour.
I agree there is a usecase for where you want to add one day to an 8am datetime, and get 8am the next day. Calling them "date operations" or "calendar operations" is not dismissing them. I got into this whole mess because I implemented calendars. That use case is the main usecase for those operations.
But that usecase is easily handled in several ways. Already today in how datetime works, you have two solutions: The first is to use a time zone naive datetime. This is what most people who want to ignore time zones should use. The other is to separate the datetime into date and time objects and add a day to the date object.
I said I was done commenting, and this is supposed to move to the datetime-sig, but this "lack of use cases" keeps coming up, so I'm going to make one more comment, repeating something I said earlier.
What *I* want aware datetimes to do is give me the correct timezone label when I format them, given the date and time information they hold. The naive arithmetic is perfect, the conversion between timezones is fine, the only thing missing from my point of view is a timezone database such that if I tell a datetime it is in zone X, it will print the correct offset and/or timezone label when I format it as a string.
That's my use case; and it is, I would venture to guess, *the* most common use case that datetime does not currently support, and I was very disappointed to find that pytz didn't support it either (except via 'normalize' calls, but why should I have to call normalize every time I do datetime arithmetic? It should just *do* it.)
Anything more would be gravy from my point of view.
Now, maybe tzinfo can't actually support this, but I haven't heard Tim say that it can't. Since the datetime is always passed to tzinfo, I think it can.
PS: annoying story: I scheduled an event six months in advance on my tablet's calendar, and it scheduled it using what was my *current* GMT offset (it calls it a time zone) even though it knew what date I was scheduling it on. Which meant the alarm in my calendar was off by an hour. I hope they have fixed this bug. I relay this because it is exactly the same problem I find to be present in pytz. If the calendar had been using aware datetimes and naive arithmetic as I describe above, the alarm would not have been off by an hour.