-
Notifications
You must be signed in to change notification settings - Fork 24
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
Enhance MET to handle CF-compliant time strings with an offset defined in months or years. #2155
Comments
Examples:
|
I think the approach stated above,
Seems like good logic. However, there's two issues I want to raise. In the last example, 3.3 years is evaluated to 1958-07-01. However, that seems like it's slightly further in time than might be desired. After adjusting the base time by 3 years, the remainder (0.3) is multiplied by 12 with a resulting 3.6 months. To me, that means the months should be incremented by 3 rather than 4, and there needs to be an increment of days as well. Using the logic of John HG mentioned that
I noticed that in the logic provided, 1.5 months goes to the 16th of the month. Do we need a special logic case where a remainder of 0.5 always takes the days to the 15th of whatever month is evaluated to? |
Need a decision for the algorithm: Day for 0.5 month
Assuming for month and year units:
Algorithm.
Examples:
|
Decision for 0.5 month: set the day to 15:
|
Is it OK not to support negative offsets, like -4.5 month or -10 years? |
Two options to support negative offsets
|
I think it's OK to ignore negative offsets for time. I've never seen it used before and can't imagine a situation where it would be appropriate. |
Modified to handle the case when the start day (the reference day) is not the first day of the month.
|
Describe the Enhancement
This issue arose via GitHub discussions dtcenter/METplus#1604 and an enhancement to the MET's support for CF-compliant NetCDF files is needed to read WOA climatology files. This enhancement supports development of the NOAA/EMC EVS verification system.
As of MET version 10.1.0, processing CF-compliant data with times defined with a months or years offset results in this warning message.
And MET uses sets the valid time to unixtime 0 which is Jan 1, 1970.
The "months" offset is commonly used for climatology data and climate simulations, and this short-coming has come up a few times in the past.
The use of months is discouraged since they vary. According to this section of the CF-convention documentation, 1 year = 365.242198781 days and 1 month = 1 year / 12. So 1 month = 30.436 days.
However, I recommend against implementing this logic. Instead, let's implement the logic that users actually intend and expect. For example, when time is defined as a value of 377.5 with the string "months since 1955-01-01 00:00:00"...
The last step is confusing. Modelers use 0.5 month to mean the 15th of the months rather than an offset of 15 days (01 + 15). Need to think about that one.
@hsoh-u also ask how to handle these cases, where the compute time does not actually exist?
Another issue is what if the start day is 29, 30 or 31.
"month since 2020-01-29 00:00:00"
"month since 2020-01-31 00:00:00"
30, Feb
31, Apr
We'd need to define logic for handling these edge cases.
Time Estimate
Estimate the amount of work required here.
Issues should represent approximately 1 to 3 days of work.
Sub-Issues
Consider breaking the enhancement down into sub-issues.
No sub-issues needed.
Relevant Deadlines
List relevant project deadlines here or state NONE.
Funding Source
2773542 (was 2793541)
Define the Metadata
Assignee
Labels
Projects and Milestone
Define Related Issue(s)
Consider the impact to the other METplus components.
No impacts.
Enhancement Checklist
See the METplus Workflow for details.
Branch name:
feature_<Issue Number>_<Description>
Pull request:
feature <Issue Number> <Description>
Select: Reviewer(s) and Linked issues
Select: Repository level development cycle Project for the next official release
Select: Milestone as the next official version
The text was updated successfully, but these errors were encountered: