BUG: start_time end_time to_timestamp bugs #2124 #2125 #1764

[changhiskhan]

@wesm can you review this plz?

The main change is I have to_timestamp default to second frequency now to get the first and last second of the Period. This doesn't quite solve #2125 since Timestamp resolution goes down to Nanos. So the question is is it appropriate to add 999999999ns to the end_time when ns doesn't exist asa period freq?

[changhiskhan]

ok how about this:

start_time : starting second
end_time : ending second
to_timestamp : defaults to 'D' freq for week or longer and 'S' otherwise. The logic here is to make it more convenient for cases like monthly_period.to_timestamp(how='e') to get 'M' freq and monthly_period.to_timestamp() to get 'MS' freq.

The alternative is to always default to 'S' so for that whole class of use case above you would need to remember to specify 'D' as the freq (e.g., annual_period.to_timestamp('D', how='e'))

What do you think? Consistency vs convenience