Not ideal behavior when updating Grib2Message datetime attributes.

[EricEngle-NOAA]

Currently, grib2io allows you to update the Grib2Message attributes refDate, leadTime, and duration. They are presented to the user as datetime.datetime and datetime.timedelta objects respectively. The attr validDate exists as a read-only attribute, but in certain PDTNs, there are elements in Section4 PDT to hold the "valid date" components (year, month, day, hour, minute, and second).

In those certain PDTs (i.e. time interval variables), the leadTime attr represents the beginning of the time period. The leadTime can be summed with the time interval of "Statistical Process" (duration attr) to find the end of the time interval.

The following table is the desired behavior when modifying datetime attributes.

Attrs	refDate	leadTime	duration	validDate
refDate	YES	NO	NO	YES
leadTime	NO	YES	NO	YES
duration	NO	NO	YES	YES
validDate	NO	NO	NO	NO

The table reads as...modifying refDate, leadTime, and duration attrs will obviously modify that attribute, but it will also modify the validDate since they are interconnected. However, the validDate cannot be modified directly and is considered read-only. Setting this attr will raise a warning.

NOTE: Even though continuous variables do not have a duration, the Grib2Message object will have a duration attributes with value of 0.

IMPORTANT: Currently (as of v2.3.0), modifying the leadTime attribute takes the duration value into consideration. This behavior will change with changes in the linked pull request.

Moving forward... It will be the responsibility of the user to make sure the refDate, leadTime, and duration attributes are correct for the given GRIB2 message. For time interval PDTs, where the valid date components are a part of the PDT, those components are gotten from the computed validDate attribute.