Strange output from timedelta_range for integer start/end

[shoyer]

Here I expected a TimedeltaIndex with 11 elements from 0 hours through 11 hours:

>>> pd.timedelta_range(0, 10, freq='H')
<class 'pandas.tseries.tdi.TimedeltaIndex'>
['0 days']
Length: 1, Freq: <Hour>

It appears that freq is taken to refer only to the step size, not the start/stop, and the unit defaults to ns like Timedelta itself? I think we should either:

1. add a separate unit argument -- but this is a subtle distinction
2. use freq to also imply the unit
3. raise on integer input (possibly in addition to 1?)

Similarly strange and somewhat inconsistent with the above example:

>>> pd.timedelta_range(0, 10, periods=100)
ValueError: Must specify two of start, end, or periods

[jorisvandenbossche]

I think your expected output is this, correct? (but then with specifying the end instead of periods)

In [129]: pd.timedelta_range(0, periods=11, freq='H')
Out[129]:
<class 'pandas.tseries.tdi.TimedeltaIndex'>
['00:00:00', ..., '10:00:00']
Length: 11, Freq: <Hour>

I think adding a unit kwarg could be useful, so you can do unit='h' instead of multiplying:

In [127]: pd.timedelta_range(0, 10*3600*1000000000, freq='H')
Out[127]:
<class 'pandas.tseries.tdi.TimedeltaIndex'>
['00:00:00', ..., '10:00:00']
Length: 11, Freq: <Hour>

I don't think using freq for this would be a good idea, as eg what should be done if you specify freq=2H? How to interpret the integer then?

In [128]: pd.timedelta_range(0, 10*3600*1000000000, freq='2H')
Out[128]:
<class 'pandas.tseries.tdi.TimedeltaIndex'>
['00:00:00', ..., '10:00:00']
Length: 6, Freq: <2 * Hours>

Also raising on integer input is not a good idea IMHO, as it is valid input (although maybe not used that much).

Possible counterargument: date_range does not have the unit kwarg that Timestamp does have, but I think for timedelta's it is much more natural to specify it as an integer.

[jreback]

I think specifying an integer and a unit is ok, as it is allowed in pd.to_timedelta. But would have to be somewhat restricted and apply ONLY to integer input (so it would default to 'ns'). The start/end just need to be convertible to Timedelta, so can be datetime.timedelta/np.timedelta64/Timedelta/string-like/offset. So integer need a helper.

Though not sure how harder it is to do:

pd.timedelta_range(Timedelta(0,unit='d'),Timedelta(10,unit='d'),freq='d')

[shoyer]

There are definitely other ways to get this done, but it is (in my opinion) rather confusing that integers arguments are treated as offsets in ns, especially given that the default frequency is different. The use of ns internally is a rather arcane implementation detail...

So my vote is that this should raise and we don't need any other changes. The main reason I like having a unit argument is that it makes it clear that the units for the bounds are not the same thing as the frequency.

[jreback]

ok on raising for integers. The problem with a sane default is that not everyone thinks is sane. ns is quite sane as that is the actual impl (and how numpy does it too).

[jorisvandenbossche]

In my opinion raising on integers in not an option. It is a perfectly valid input (as it is also the default for Timedelta), so why would we raise? OK, because we think it will confuse a lot of users. And in that case it is a bit of a balance we should seek here, but I lean to better documenting it (and adding the unit kwarg).

Also, when would you raise? Only if the end is an integer? Or also if the start is an integer? Because I don't think the following should raise:

In [9]: pd.timedelta_range(0, periods=10, freq='H')
Out[9]:
<class 'pandas.tseries.tdi.TimedeltaIndex'>
['00:00:00', ..., '09:00:00']
Length: 10, Freq: <Hour>

[jreback]

I think you have to have start and end specified with no freq THEN it will require a unit (or raise)
as unspecified/ambiguous operation (e.g. would be ns by default but that should be explicit).