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

Thu Jul 30 18:19:25 CEST 2015

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 <tim.peters at gmail.com> wrote:

> [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
> ;-)
> _______________________________________________
> Datetime-SIG mailing list
> Datetime-SIG at python.org
> 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

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/datetime-sig/attachments/20150730/bfcca980/attachment-0001.html>