Feature Requirement: calendar fixes

[truth-quark]

TODO: what is the requirement for calendar fixes?
TODO: add unit tests

Are these the relevant code sections?

• https://github.com/ACCESS-NRI/um2nc-standalone/blob/main/src/um2netcdf.py#L24-L46
• https://github.com/ACCESS-NRI/um2nc-standalone/blob/main/src/um2netcdf.py#L138-L160
• https://github.com/ACCESS-NRI/um2nc-standalone/blob/main/src/um2netcdf.py#L169-L185

[MartinDix]

Control runs often use nominal dates (or "model years"), starting from year 1. ESM1.5 uses a proleptic Gregorian calendar. The UM and iris only distinguish between 360 day and standard, so the calendar attribute isn't set correctly. This can causes date offsets with some post-processing software that's strict about the proleptic Gregorian vs standard=Julian/Gregorian distinction.

import iris
pr = iris.load_cube('/g/data/tm70/esm15_testing/sample_output/aiihca.paa1jan', 'rainfall_flux')
print(pr.coord('time'))

DimCoord :  time / (hours since 1970-01-01 00:00:00, standard calendar)
    points: [0101-01-16 12:00:00]
    bounds: [[0101-01-01 00:00:00, 0101-02-01 00:00:00]]
    shape: (1,)  bounds(1, 2)
    dtype: float64
    standard_name: 'time'

[aidanheerdegen]

Note that MOM5 also has calendar issues, in that it claims to be gregorian (but also says it doesn't support gregorian in the code comments), but the calendar logic is for proleptic gregorian

COSIMA/access-om2#117

We could/should fix MOM5.

[aidanheerdegen]

This comment:

#118 (comment)

Suggests there are only 3 supported calendar types. If that is the case the code should explicitly NOT support other types, and return an error to users.