[Datetime-SIG] "Use cases" (was Re: [Python-Dev] Status on PEP-431 Timezones)

[Tim Peters]

[moved from python-dev]

[Lennart Regebro <regebro at gmail.com>]
>>> 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
;-)