add new variables 'VALID_YEAR' and 'VALID_MONTH'

[TatianaBurek]

Describe the Enhancement

*Add new variables 'VALID_YEAR' and 'VALID_MONTH' similar to the existing ' VALID_HOUR' and use SQL functions YEAR(fcst_valid_beg) and MONTH(fcst_valid_beg) to calculate the values on demand.
These variables would help with plots like Perry described:

Is it possible to make a plot with the x-axis being, say, a time period (like April 1-30), but one trace being 2019 and the other trace being 2020? This looks useful with forecast hour as the independent variable, but I'd like to know if I can have a time series comparing the same month for different years.
*

Time Estimate

Estimate the amount of work required here.
Issues should represent approximately 1 day of work.

Sub-Issues

Consider breaking the enhancement down into sub-issues.

• Add a checkbox for each sub-issue here.

Relevant Deadlines

NONE.

Funding Source

NONE.

Define the Metadata

Assignee

• Select engineer(s) or no engineer required
• Select scientist(s) or no scientist required

Labels

• Select component(s)
• Select priority
• Select requestor(s)

Projects and Milestone

• Select Repository and/or Organization level Project(s) or add alert: NEED PROJECT ASSIGNMENT label
• Select Milestone as the next official version or Future Versions

Define Related Issue(s)

Consider the impact to the other METplus components.

• METplus, MET, METdatadb, METviewer, METexpress, METcalcpy, METplotpy

Enhancement Checklist

See the METplus Workflow for details.

• Complete the issue definition above, including the Time Estimate and Funding Source.
• Fork this repository or create a branch of develop.
  Branch name: feature_<Issue Number>_<Description>
• Complete the development and test your changes.
• Add/update log messages for easier debugging.
• Add/update unit tests.
• Add/update documentation.
• Push local changes to GitHub.
• Submit a pull request to merge into develop.
  Pull request: feature <Issue Number> <Description>
• Define the pull request metadata, as permissions allow.
  Select: Reviewer(s) and Linked issues
  Select: Repository level development cycle Project for the next official release
  Select: Milestone as the next official version
• Iterate until the reviewer(s) accept and merge your changes.
• Delete your fork or branch.
• Close this issue.

[JohnHalleyGotway]

@TatianaBurek is adding VALID_YEAR and VALID_MONTH sufficient (to go along with VALID_HOUR) for creating a plot where the X-axis is the day of the year and the series are lines for different years? Do we perhaps also need VALID_DAY? Or perhaps instead of VALID_MONTH, we need VALID_MONTH_DAY or VALID_DAY_OF_YEAR?

[TatianaBurek]

I don't know if VALID_YEAR and VALID_MONTH would be sufficient but it would be easy to implement.
We could also add VALID_DAY_OF_YEAR as DAYOFYEAR(fcst_valid_beg).
But it is harder with VALID_MONTH_DAY

[JohnHalleyGotway]

I recommend that we get some input from @PerryShafran-NOAA. While I do like the VALID_DAYOFYEAR, I suspect that leap years will wreak havoc. That'll shift all the data forward by one day every 4 years. And I assume that the scientists would like all the March 1st data to line up whether or not the previous day was February 29th. @PerryShafran-NOAA am I correct in assuming you'd basically want to ignore 2/29 when comparing performance across years?