COMPAT: periods needs coercion to np.int64 in _generate_regular_range

[jreback]

https://github.com/pydata/pandas/blob/master/pandas/tseries/index.py#L1768

a simple np.int64(periods) will suffice

(and tests of course)

This needs to guaranteed to be int64 as a result (e.g. if this is in32 it will have an internal overflow which will make it have a valid but weird result)

[Garrett-R]

Hey @jreback,

I'd like to try tackling this one as a first PR. Do you mind giving an example line of code that would cause _generate_regulate_range to have an overflow?

I thought maybe it was this line, but I couldn't find an example. I tried

pd.DatetimeIndex(start='2005', periods=np.int32(1e9), freq='s')

but in my case, stride was a Python int, and the result of periods*stride is a np.int64, so no overflow.

[jreback]

you actually need a bigger number

try np.iinfo(np.int32) + 1

[Garrett-R]

Sorry, I'm probably being a bit dense here, but are you suggesting I try something like:

periods =np.iinfo(np.int32).max + 1
periods = np.int32(periods)
pd.DatetimeIndex(start='2005', periods=periods, freq='s')

In that case, the overflow happens on the second line. I can't think of how to produe an overflow inside _generate_regular_range...

[jreback]

look at @jorisvandenbossche example in the linked issue #8907
iirc that example generates the issue (in the index construction)

[Garrett-R]

Cool, I think I know why I wasn't able to reproduce the bug. @jorisvandenbossche is on 32-bit Linux and I'm on 64-bit Linux, so for me, periods gets promoted to np.int64 before having a chance to overflow, whereas for @jorisvandenbossche, I think it probably stays as np.int32.

Alright, I'll do your proposed fix now.