Is there any disagreement that both Duration and Period (to use the Noda terms) operations have important and common use-cases?
Granted, if not, that doesn't tell us anything about what should be supported in the stdlib, but it seems odd to be arguing about something this basic. -Chris On Wed, Jul 29, 2015 at 6:35 PM, Tim Peters <[email protected]> wrote: > [moved from python-dev] > > [Lennart Regebro <[email protected]>] > >>> 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. > > Ever get the feeling we use languages that share many words but few > meanings? I do ;-) > > I can tell you what "use case" means to me: task T is a use case for > gimmick G if and only if G can be used straightforwardly to accomplish > T. That's all. By my meaning, you have been shown use cases. > > > 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. > > In context, "you usually dismiss them" meant you refuse to accept them > as being use cases (dismiss them for that purpose). Which you do. I > had no intent to imply that you, e.g., held such apps in contempt > (which is a possible meaning of "dismiss"), and apologize if it came > across that way. > > > I got into this whole mess because I implemented calendars. That use > > case is the main usecase for those operations. > > By my definition, I certainly agree that mucking with calendars is a > use case for calendar operations (even without knowing precisely what > "calendar operations" means). > > > But that usecase is easily handled in several ways. > > By my definition, the number of ;_possible_ straightforward ways to > accomplish T is irrelevant to whether T is a use case. It's a use > case for all straightforward ways of accomplishing T. > > > Already today in how datetime works, you have two solutions: The first > > is to use a time zone naive datetime. > > That's not a solution at all to the specific kinds of apps I (& > others) sketched before. Those apps _also_ need to keep track of > local times in multiple time zones, and _also_ need to convert times > among those time zones. Their datetime objects need to have fully > capable tzinfo members. They also need to compute simple kinds of > "calendar operations". > > > 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. > > Same objection. There was never a claim that _all_ applications are > "use cases" for the status quo; the claim was that you were given > _some_ applications that were use cases. > > > But most importantly, there are better ways to solve this that > > datetime today doesn't support at all: > > "There's a better way to solve it" also has no bearing, in my > definition of "use case", on whether a particular T _is_ a "use case" > for G. There are typically many distinct ways to accomplish a given > T; T is typically a use case for many gimmicks. > > > 1. You can use something like dateutil.rrule for repeating events. > > (works today, but requires a third-party module). > > I agree the apps in question are use cases for some dateutil gimmicks. > > > 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). > > This one is too sketchy for me to guess. If the claim is just that > _some_ kind of timedelta variant could be created that would handle > the specific apps in question if arithmetic worked differently _and_ > the implementations of datetime arithmetic were changed to do > something quite different from the new default when given an instance > of that timedelta variant, then sure. Whether that would be a "better > way" is clear as mud without fleshing out a world of details. > > > 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. > > Don't know anything about those, so no comment. > > In any case, a full-featured "calendar operations" module would (IMO) > be a welcome addition. In effect, the builtin datetime-timedelta > arithmetic makes some kinds of "calendar operations" dead easy, but > they're limited to moving. in naive time, by (in conceptual terms) > linear combinations of days, weeks, and (rarely) hours. > > > 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. > > And, e.g., you've never seen the description of the cross-timezone > meeting-scheduling app? It wasn't brought up by me, but I have > summarized it for you before. It needs fully aware datetime objects > (both to mirror local clocks, and to convert between timezones), and > it needs simple "same local time a week from now" operations. All > very easily done with the status quo (the only "hard part" is getting > the right tzinfo objects to begin with), and so is unquestionably - by > my definition - a use case for doing naive arithmetic on aware > datetimes. Not only "a" use case, but a good one. I can't imagine a > simpler way (for the user) to accomplish what that app needs. > > > Because that's what datetime implements. That's what I want a usecase > > for. > > And you've been given some. I expect you'll disagree, but if you do > I'll let it end with your response. > > > "I want the same time next day" is not such a usecase. > > With just that much In isolation, no, I agree it isn't a _good_ use > case for doing naive arithmetic on an aware datetime object. But > since it _does_ solve the problem, by my definition I'm afraid it does > count as _a_ use case. If, for reasons neither stated nor denied, > that same app not only needs 'same time next day" but also needs "and > then I need to convert same time next day to some other timezone > (e.g., I'm in a hacker network and my payload won't be ready until > same time next day, and then I have to coordinate releasing the > payload with my criminal partners in China). then that's a fine use > case. Yes, I realize there are other ways that can done. Doesn't > change that it's _a_ use case as is. > > >> 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. > > Of course people use whatever is most convenient to get the task at hand > done. > > When people are already getting correct results for _their_ purposes, > using obvious (to them) code, in what way(s) would changing the > arithmetic make those apps work better? I mean, of course, the same > apps that are already working fine. > > > ... > > I stopped arguying for changing datetime two days ago. I've also > > mentioned that several times. > > Yet the argument never ends ;-) Seriously, I hope you find a way to > get interested in this again. You have a wealth of experience that's > valuable here! > > >> 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. > > Happy to look at specific examples. In truth, I _do_ recall some, but > not since Python 1.0.0 was released. > > Example: waaaaaaaaaay back when, ints used (an illusion of) > infinitely wide 2's-complement internally, but longs used (an illusion > of) infinitely wide 1's-complement internally. Both were intended and > documented. > > One consequence: if you had a negative integer K and shifted it > right, the value of the result could differ depending on whether > type(K) was int or long. This made nightmares for my code at the > time, because I needed to mix signed ints and signed longs frequently. > Guido changed it (so that all integer types used the 2's-complement > scheme). But despite that Python had only 2(*) users at the time, he > was still cautious and apologetic about it. > > (*) Maybe 3. I used an old script to compute this, but the exact > value got lost due to the "different representations, with visible > consequences, for negative integers of different types" design flaw > ;-) > _______________________________________________ > Datetime-SIG mailing list > [email protected] > https://mail.python.org/mailman/listinfo/datetime-sig > The PSF Code of Conduct applies to this mailing list: > https://www.python.org/psf/codeofconduct/ > -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected]
_______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
