[Lennart Regebro] \>>> I have yet to see a use case for that. [Tim]
Of course you have. When you address them, you usually dismiss them as "calendar operations" (IIRC).
'[Lennart]
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.
But most importantly, there are better ways to solve this that datetime today doesn't support at all:
1. You can use something like dateutil.rrule for repeating events. (works today, but requires a third-party module). 2. timedelta could not incorrectly pretend that one day is always 24 hours, but actually handle days separately, and always increase the days when a day is given. (This would however mean we no longer can support fractional days). 3. There could be a datetelta() object that makes operations on dates, leaving hours, minuts, seconds and microseconds alone, or something like Lubridates Perod and Delta objects, where a Period() essentially operates on wall time, and a Duration() operates on real time.
So that's not the usecase I'm asking for. I am specifically asking for a usecase where I want an object that is timezone aware, but ignores the timezone for everything other than conversion to other timezones. Because that's what datetime implements. That's what I want a usecase for. "I want the same time next day" is not such a usecase.
And I don't want that use case for you to convince me that we shouldn't change datetime. You say it breaks too much. OK, if you say so. I don't know. I want to know if that use case actually exists, because I don't think it does.
But it doesn't matter whether you _call_ them "calendar operations", or anything else. What they're called doesn't change any of the high-order bits: they are use cases, they already work, they have worked that way for a dozen years (an eternity in "computer time"), they were always intended to work that way, and the docs have always said they work that way.
They only work like that because people have adapted to how datetime does things. If datetime had done this properly from the start, it would have worked even better.
I do think you're missing my fundamental objection: no matter what intended and documented thing datetime (or any other module) has done all along, and regardless of whether I loved it or hated it, I'd be just as annoying about insisting we cannot intentionally break existing code
I stopped arguying for changing datetime two days ago. I've also mentioned that several times.
using that thing in non-trivial ways without a justification so compelling that I can't recall a case of it ever happening.
Well, I've seen several of those on Stackoverflow.
//Lennart