Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change defaults for parse_metar_file #1327

Closed
dopplershift opened this issue Feb 27, 2020 · 3 comments · Fixed by #1523
Closed

Change defaults for parse_metar_file #1327

dopplershift opened this issue Feb 27, 2020 · 3 comments · Fixed by #1523
Assignees
Labels
Area: IO Pertains to reading data Type: Bug Something is not working like it should
Milestone

Comments

@dopplershift
Copy link
Member

Right now, the signature of parse_metar_file is:

parse_metar_file(filename, year=datetime.now().year, month=datetime.now().month):

This can create some confusion:

  • Generated docs show fixed default values, taken when the docs were last built (i.e. currently parse_metar_file(filename, year=2020, month=1))
  • If a user has a long running process, IPython/Jupyter window open for awhile, etc., calls to parse_metar_file are not going to use the current year/month, but the year/month when MetPy was imported.

So we should change this to default to None, and then check for None and convert that to the appropriate values.

@dopplershift dopplershift added Type: Bug Something is not working like it should Area: IO Pertains to reading data labels Feb 27, 2020
@dopplershift dopplershift added this to the 1.0 milestone Feb 27, 2020
@akrherz
Copy link
Contributor

akrherz commented Feb 27, 2020

My opinion is that you need more granularity here to also specify the day, so to get things right when parsing archived METARs around the first of the month.

@kgoebber
Copy link
Collaborator

kgoebber commented Feb 28, 2020

So I couple with @akrherz as I have run into this issue quite a bit and think we may need to add in hour as well. Here is some code that would work to alleviate the problem, but with the need to have year, month, day, and hour, then we might as well make the input be a date time object.

from datetime import datetime, timedelta

import numpy as np

file_day = 31
file_hour = 23
file_minute = 50

known_date = datetime(2020, 2, 1, 0)
try:
    file_date = datetime(known_date.year, known_date.month, file_day, file_hour, file_minute)
except:
    file_date = datetime(known_date.year, known_date.month-1, file_day, file_hour, file_minute)

if np.abs(known_date - file_date) > timedelta(hours=1):
    if month == 1:
        file_date = datetime(known_date.year-1, 12, file_day, file_hour, file_minute)
    else:
        file_date = datetime(known_date.year, known_date.month-1, file_day, file_hour, file_minute)

print(known_date)

print(file_date)

Output:

2020-02-01 00:00:00
2020-01-31 23:50:00

@akrherz
Copy link
Contributor

akrherz commented Mar 3, 2020

So I couple with @akrherz

Only on days ending with the letter 'y'.

Likely preaching to the choir here, but there's craziness on the noaaport feed, mostly international METARs

  1. Products that come every hour with the same WMO header timestamp, for example one is coming today with a day timestamp of 31.
  2. Products that come with a valid and current WMO header timestamp, but have actual METARS with various random dates that could be in the future or past or neither.
  3. Products with valid WMO headers that update hourly, but the same METAR repeated every hour that is likely valid some number of years ago.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: IO Pertains to reading data Type: Bug Something is not working like it should
Projects
None yet
4 participants