"Use cases" (was Re: [Python-Dev] Status on PEP-431 Timezones)
[moved from python-dev]
[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.
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 ;-)
participants (1)
-
Tim Peters