On Sat, Aug 22, 2020 at 10:29 AM Richard Damon <rich...@damon-family.org>
wrote:
One issue with allowing Months here is then suddenly an interval becomes
> dependent on when it is, so needs to be keep in a complex form, as a
> month (and year) are variable length time units.
>
months are already not supported by timedelta, I'm not sure why this was
brought up.
On 8/22/20 1:07 PM, Stephen J. Turnbull wrote:
> > If anything is to be added, I would prefer using ISO 8601 durations.
>
I agree here -- I know I"ve written a little wrapper, "asdatetime" that
takes either a datetime object or a ISO 8601 string, so my scripting users
have an easier API. Adding one for timedetla makes sense to me.
However, the "problem" witht he ISO Duration standard is that it's what I
call a "calendar" description -- e.g. this date next month, not a timedelta
description -- the datetime module already mingles those a bit too much in
my mind, but we really shoudln't make it worse, and while timedelta does
support days and weeks, it does not support months, because months are not
a well defined time interval.
So if we want to go with an ISO-like, how about the time portion of a
datetime string.
T12:23:34:12
In any case, I have to say that I find the OP's example pretty darn
unreadable:
datetime.parse_duration("2w50d8h5m27s10ms2000us")
Do we really need to support weeks, or even days? Again, those are good fro
Calendering operations, but those aren't well supported by timedelta anyway.
Another option, which has been brought up on this list before is a set of
utilties for comon durations. I actualyl have these in y code as well:
days(n=1)
hours(n=1)
minutes(n=1)
seconds(n=1)
I find these very useful for scripting where the scrit writer may not be
all that familiar with python and the datetime module.
And while:
hours(2) + minutes(30)
Is only arguably more readable than:
timedelta(hours=2, minutes=30)
I find that in my uses, folks have a timescale for there application, and
rarely need toim mix them. (and hours(2.5) workd fine as well.
TL;DR:
-0 on the full string parsing as proposed by the OP
-1 on ISO duration string
+0 on using teh time portion of the ISO datetime string
+1 on named utilites: days(), hours(), minutes(), seconds(), microsecronds()
-CHB
> > https://en.wikipedia.org/wiki/ISO_8601#Durations
> >
> > The main differences are use of "P" and "T" to signal that it is a
> > duration and allow both minutes and months to be identified by "M",
> > and decimal fractions of the smallest unit present are permitted, and
> > seconds is the smallest unit, so the above would be represented
>
>
>
> Also, the math gets funny when you do things like this. Jan 31st + 1
> month is Feb 28th (or 29th) + 1 month is March 28th (or 29th), but Jan
> 31st + 2 Months is March 31st, Similarly, adding a month and then
> subtracting a month doesn't always get you back to your starting time.
>
> --
> Richard Damon
> _______________________________________________
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/PAHZ6QSHPFZ5ZT57GMJDLTZLCAKQOVZ6/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Christopher Barker, PhD
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/BKTVEMFGNQ4NRF5BPIFHUTSQBFNRKLAK/
Code of Conduct: http://python.org/psf/codeofconduct/
