REF: de-duplicate code in libperiod

[jbrockmendel]

discussed a few months ago, this gets rid of date_info_from_days_and_time and instead re-uses pandas_datetime_to_datetimestruct

[jreback]

elif on these?

[jbrockmendel]

updated+green

[jbrockmendel]

cc @WillAyd trying to figure out which of the current CI failures are false-positives, is this one from Travis a real problem?

pandas/_libs/tslibs/period.c:9227:11: error: ‘__pyx_v_factor’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

   __pyx_r = (__pyx_v_sub * __pyx_v_factor);

           ^

pandas/_libs/tslibs/period.c:8995:26: note: ‘__pyx_v_factor’ was declared here

   __pyx_t_5numpy_int64_t __pyx_v_factor;

                          ^

cc1: all warnings being treated as errors

building 'pandas._libs.tslibs.resolution' extension

[WillAyd]

I'm assuming your latest commit fixes the issue, but yea I think just telling you that factor could potentially be uninitialized if none of the conditions branch, so either need to guarantee it branches or initialize to a value

[WillAyd]

Any reason you don't just pass the reference to dts in the call above?

[jbrockmendel]

Because the caller might still need dts

[WillAyd]

Doesn't calling dt64_to_dtstruct do exactly what the next 5 lines of code do anyway?

[jbrockmendel]

i can confirm that just passing dts does Break The World. IIRC part of whats going on here is that dts may be out of bounds for dt64[ns]

[WillAyd]

Ah OK. Thanks for checking - seems strange to have to do this but probably a separate issue then