Python binding for quarters

[shaneding]

Closes #8676.
This PR adds python bindings for #8779.

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (branch-21.10@115f3b6). Click here to learn what that means.
The diff coverage is n/a.

@@               Coverage Diff               @@
##             branch-21.10    #8862   +/-   ##
===============================================
  Coverage                ?   10.58%           
===============================================
  Files                   ?      116           
  Lines                   ?    19067           
  Branches                ?        0           
===============================================
  Hits                    ?     2018           
  Misses                  ?    17049           
  Partials                ?        0           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 115f3b6...0502eeb. Read the comment docs.

[shaneding]

rerun tests

[shaneding]

rerun tests

[shaneding]

rerun tests

[shaneding]

rerun tests

[isVoid]

lgtm, good work!

[galipremsagar]

I think we could probably save some memory that would go un-used here.

@beckernick Is it a necessity, in this case, we should be matching pandas return dtype(i.e., int64)?

The related libcudf method also seems to be returning int16, instead of int8: https://github.com/rapidsai/cudf/pull/8779/files#diff-76e529bce1f51fca7ea3193f09c6e95906410a82bcc03a9271553b8527468052R218

@shaneding any reason why we choose int16 over the lowest possible dtype?

[shaneding]

I think we could probably save some memory that would go un-used here.

@beckernick Is it a necessity, in this case, we should be matching pandas return dtype(i.e., int64)?

The related libcudf method also seems to be returning int16, instead of int8: https://github.com/rapidsai/cudf/pull/8779/files#diff-76e529bce1f51fca7ea3193f09c6e95906410a82bcc03a9271553b8527468052R218

@shaneding any reason why we choose int16 over the lowest possible dtype?

The main reason was because within datetime_ops.cu most operations returned an int16 so we decided to go with it for compatibility reasons, this was discussed in a thread earlier too.

[galipremsagar]

@gpucibot merge