[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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
