ENH: Have inferred_freq set offset. Have freq always try to infer.

[jseabold]

I'm on the fence about this. Having a property with side effects doesn't quite sit right to me. But I think it kinda makes sense here. If it didn't set freq, then it really doesn't make sense for freq to exist. I'd just use inferred_freq all of the time.

Now calling freq always tries to infer the frequency. Why not? Seems sensible to me. inferred_freq is kind of redundant now, but I left it anyway. I was never really sure of the rationale for its existence.

[jreback]

AFAICT this was not done for 2 reasons:

• performance, unless you are doing a time-series operation that needs to freq no need to 'compute' it (if it is not already specified)
• their is not an easy way to represent 'no freq' except by None. So you can have a freq even though it really shouldn't (I have seen this when you have 5 mon-fri days, it get's inferred to a business day freq), and thus the inferernce can be a tad ambiguous (see above)

maybe @wesm has a different view

another possible reason (and the reason the tests fail) is that merge/join doesn't want this and can lead to spurios errors, e.g. joining a single day that happens to be a month-end to a 'daily' frequency, is allowed but if you already have frequency assigned then it will fail.

[jseabold]

I see your points, though the join thing seems more like a corner case implementation detail.

Ok, so pretty much I should just always used inferred_freq in statsmodels and take the possible (one-time) performance hit. The reason for this is that freq is only defined if it's given when the Index is created, but even then you can't count on freq being defined because freq gets stepped on when you're resetting indices, etc. #6631.

This just seems so esoteric from a user standpoint. I.e., freq == user_defined_freq unless it's been stepped on, and infer_freq == always gives me something if it can. It seems like 98% of the use-cases want the latter. I'm biased to data that almost always has a sane frequency.

[jreback]

I think the reset case is really the issue. Say you reset, then set the index, freq is lost (and must be re-inferred), because the meta-data is not 'kept' anywhere. I suppose you could have a flag in DatetimeIndex that would 'force' inference to happen. Might make sense for statsmodels.

Actually the reset/set case could be dealt with by caching the indexes on a reset/set. hmm.

[jseabold]

Right now I'm just leaning towards always using infer_freq (lazily) and the status quo. All the dates magic we can do requires some kind of frequency (forecast, backcasting, re-sampling, etc.). Thinking about it, dates really aren't that useful to have around without frequencies (from where I sit). I just have to remember, because it's not all that intuitive. If infer_freq is your performance bottleneck, then you should likely be closer to the metal anyway. Plus the vast majority of the time users load in data rather than creating a DatetimeIndex, passing in a freq. It's best if users don't have to think about frequencies and periodicities at all.

[jreback]

I don't think you will have an issue as long as you don't reset/set (or pay the penality if you do). The more I think about it the more that's the reason it doesn't do this automatically. reset/set are cheap operations and you want them to stay that way.