Error on the leap day time increment

[junwang-noaa]

Describe the bug Today two UFS applications RRFSv1 and AQMv7 parallel runs failed with the same error message:

FATAL from PE  2713: diag_manager_mod::register_diag_field:  file=fv3_history: Invalid date. Date=2025-02-29 00:00:00

The tests failed for both "julian" and "gregorian" calendar type. Both runs have the following in the diag_table:

20240229.06Z.C793.32bit.non-hydro.regional
2024 02 29 06 00 00

"fv3_history",             1,  "years",   1, "hours", "time"
"fv3_history2d",           1,  "years",   1, "hours", "time"
...

After changing the two lines with file names to:

"fv3_history",             1,  "hours",   1, "hours", "time"
"fv3_history2d",           1,  "hours",   1, "hours", "time"

Both tests ran successfully. It looks to me that the time increment "1 year" for the leap day 20240229 is not correctly computed.

To Reproduce Run a test with 20240229 ICs with diag_table above.

Expected behavior The model should not failed with error of wrong date: 20250229. The time manager should give 20250228 for a 1 year increment.

System Environment Describe the system environment, include:

• OS: [e.g. RHEL 7.2]
• Compiler(s): Type and version [e.g. Intel 19.1]
• MPI type, and version (e.g. MPICH, Cray MPI, openMPI)
• netCDF Version: For both C and Fortran
• Configure options: Any additional flags, or macros passed to configure

Additional context Add any other context about the problem. If applicable, include where any files that help describe, or reproduce the problem exist.

[uramirez8707]

@junwang-noaa What release of FMS are you using for this?

[junwang-noaa]

We are using FMS 2023.02.01.

[uramirez8707]

Can you try out of this branch fixes your issue? leap_yr_fix_2023.02.01 of git@github.com:uramirez8707/FMS.git

[junwang-noaa]

@uramirez8707 I tested your branch. The test now runs fine. Thanks

[uramirez8707]

Fixed in #1479 for the new and old diag manager.