Should METAR parsing have more datetime business logic added?

[akrherz]

Whilst considering the PR for #2701, I realized that there are some other painful edge cases in MetPy + METAR parsing. Presently, MetPy requires the user to either:

1. Apriori know the year and month of the METAR / METAR file being passed to MetPy or
2. Let MetPy guess the year and month based on the calendar UTC date.

The issue is that neither of those will work for the situation of a user processing a stream of observations from a system like NOAAPort / LDM IDD. They will have situations where the METAR day, WMO header date, and calendar date may not match.

Should all this business logic / boilerplate be shunted to every user attempting to parse METARs with MetPy?

In python-metar we do have business logic that attempts to help the user out by using the current utcnow() value to more accurately guess a timestamp when no month/year is provided to the parsing library.

Should a similar approach be added to MetPy?

[dopplershift]

I think the short answer is yes, so I've opened #2707 to discuss as an enhancement.