set default METAR year, month from UTC date

[akrherz]

closes #2700

Description Of Changes

METAR is a horrible format that provides just a UTC day, so we have to make life choices to figure out what the month and year is for this day. MetPy previously assumed a default year and month matching the current system localized date and not the current UTC date.

Checklist

• Closes Bug with 'date_time' not reading the next month from METAR properly #2700
• Tests added
• Fully documented

No idea how this can be tested outside of doing naugthy things to python's datetime module?

[dopplershift]

Thanks for finding and fixing. Is there any reason you didn't use datetime.utcnow() instead?

I can't think of any way to test realistically.

[dopplershift]

I stand corrected. If we monkey patch time.time() to return what we want, that will affect things the right way. I can push the test if you have no clue what I'm talking about.

[akrherz]

Is there any reason you didn't use datetime.utcnow() instead?

I did, but then I read the python docs and it told me the preferred way.

[akrherz]

If we monkey patch time.time() to return what we want, that will affect things the right way. I can push the test if you have no clue what I'm talking about.

I can likely try that later tonight or if you want to do it, go for it.

[akrherz]

Eh, @dopplershift, I could not figure it out. It also gets tricky as one has to ensure you have a situation of the current datetime (timezone could be anything around the world when this code runs) is for the previous month. I tried setting the TZ os.environ variable for this purpose, but it wasn't doing what I hoped either...

[dopplershift]

Looks like datetime is going to be uniquely problematic to monkeypatch for testing, so we can just put this in.