BUG: iris pp treats standard calendar as a proleptic gregorian and ignores real proleptic gregorian calendars

[cpelley]

iris/lib/iris/fileformats/pp_save_rules.py

Lines 398 to 404 in 75c7570

	if time_coord is not None:
	if time_coord.units.calendar == "360_day":
	pp.lbtim.ic = 2
	elif time_coord.units.calendar == "standard":
	pp.lbtim.ic = 1
	elif time_coord.units.calendar == "365_day":
	pp.lbtim.ic = 4

Standard calendar cannot be treated as a Proleptic Gregorian for dates 1582-01-01
More context here: ancil/ticket #1159

UM F03 more recently clarified that the calendar it expects isn't Standard but a Proleptic Gregorian. Not only is iris pp save ignoring time coordinates with proleptic_gregorian calendars entirely, it also allows saving Standard dates prior to 1582-01-01 (as though they are proleptic gregorian dates when they are not).

[github-actions]

In order to maintain a backlog of relevant issues, we automatically label them as stale after 500 days of inactivity.

If this issue is still important to you, then please comment on this issue and the stale label will be removed.

Otherwise this issue will be automatically closed in 28 days time.

[nhsavage]

this is still important but I don't have any time to fix it myself

[wjbenfold]

If I understand this issue and the PP spec correctly, it isn't possible to save a PP file with a non-Proleptic Gregorian calendar. Possibly behaviours for Iris when asked to save a cube with a Standard calendar seems limited to

• leave the calendar unconverted and don't warn (current behaviour)
• leave the calendar unconverted and warn
• throw error (bad, breaks valid existing code)
• warn then convert to Proleptic Gregorian calendar then save (breaking change)
• silently convert to Proleptic Gregorian calendar then save (breaking change)
• two or more of the above behaviours, selected by a flag (which would need a default)

Are there other alternatives? Which of these would be preferred?

[nhsavage]

taking this back to basics. The problem is that the orginal UMDP F3 which was the basis of the pp load and save rules was somewhat lose in its teminology and referrred to the UM's calendar as a Standard calendar in one place and Proleptic Gregorian somewhere else. On closer inspection, I determined that it is in fact Proleptic Greogrian. However, the pp load and save rules are treating it as Standard

This means there is a symetrical error here:
https://github.com/SciTools/iris/blob/main/lib/iris/fileformats/pp.py#L1064

I thefore think there are actually two changes needed here which should cancel out in all round trip pp tests:

in pp.py change

calendar = cf_units.CALENDAR_STANDARD
to
calendar = cf_units.CALENDAR_PROLEPTIC_GREGORIAN

and in

pp_save_rules.py

change

elif time_coord.units.calendar == 'standard':

to

elif time_coord.units.calendar == 'proleptic_gregorian':

[nhsavage]

assuming a round trip with pp data is unchanged, then there are two other cases:

1. loading from pp and saving to some other format e.g. netCDF - this will change the calendar of the output and can be considered a bug fix which changes results
2. loading from other file formats which state that the data has Standard calendar - this is the hard one.
   a. we could throw an error here, which would be justified in that UM doesn't support proleptic gregorian calendars
   b. we could convert to proleptic gregorian. This would only affect data in Standard calendar a with a time base or a date before 1582. This is a real niche issue as almost all climate models use a Proleptic Gregorian not a Standard calendar as otherwise you need a lot of calendar code to cope with the transition from the Julian to the Gregorian calendar.

[nhsavage]

What I could probably do is make the above changes (except the conversion of standard calendar) and then see which, if any, of the tests break

[wjbenfold]

SciTools/cf-units#203 currently needs parallel changes in Iris, which seem quite relevant here - notably that pp files don't handle cf's "standard" calendar

[wjbenfold]

1. loading from pp and saving to some other format e.g. netCDF - this will change the calendar of the output and can be considered a bug fix which changes results

I agree that this is a bug fix. Given the likelihood that downstream users have a workaround it seems like a breaking change. We could look at hiding it behind a FUTURE flag or something (though I'm not 100% on what that entails)

2. loading from other file formats which state that the data is Standard calendar - this is the hard one.
   a. we could throw an error here, which would be justified in that UM doesn't support proleptic gregorian calendars
   b. we could convert to proleptic gregorian. This would only affect data in Standard calendar a with a time base or a date before 1582. This is a real niche issue as almost all climate models use a Proleptic Gregorian not a Standard calendar as otherwise you need a lot of calendar code to cope with the transition from the Julian to the Gregorian calendar.

I'd be happy converting to the right calendar and then doing the save without asking the user. I think this is breaking in the same way as the other effect - it invalidates workarounds / changes results that should be reproducible.

[rcomer]

Sorry I’ve not read this thread in detail, but SciTools/cf-units#185 seems relevant, and I understand @larsbarring already has a branch for it.

[rcomer]

1. loading from pp and saving to some other format e.g. netCDF - this will change the calendar of the output and can be considered a bug fix which changes results

I agree that this is a bug fix. Given the likelihood that downstream users have a workaround it seems like a breaking change. We could look at hiding it behind a FUTURE flag or something (though I'm not 100% on what that entails)

I think this will break more than just saving to other formats. For example, if you plot a time series and your calendar is "standard", the values are converted to datetime.datetime and matplotlib handles them out of the box. For any other calendar, we rely on nc-time-axis, where features such as date-locators and -formatters are (probably?) not as mature. So we risk breaking a lot of plotting code.

iris/lib/iris/plot.py

Lines 590 to 608 in 75c7570

	if coord.units.calendar == "standard":
	r = [datetime.datetime(*date) for date in dates]
	else:
	try:
	import nc_time_axis # noqa: F401
	except ImportError:
	msg = (
	"Cannot plot against time in a non-standard "
	'calendar, because "nc_time_axis" is not available : '
	"Install the package from "
	"https://github.com/SciTools/nc-time-axis to enable "
	"this usage."
	)
	raise IrisError(msg)
	r = [
	cftime.datetime(*date, calendar=coord.units.calendar)
	for date in dates
	]

For many (most?) UM applications, the data won't go back far enough for the standard/proleptic_gregorian distinction to be meaningful, so I think it would be good to permanently retain the option of cubes loaded from PP having the "standard" calendar.

[nhsavage]

it sounds like this is an issue we will have to live with. Trying to make this backward compatible seems very hard but there is no consensus to make it a breaking change, so we will have to live with it. I propose to close this issue as "won't be fixed"

[rcomer]

As I understand it, we are only just now starting to have climate configurations with a proper calendar, whereas historically they were 360_day. So the issue could start to become a genuine problem where it wasn't before (though I'm not sure how far back even the climate experiments go).

[wjbenfold]

We make breaking changes sometimes, and with good reasons. This will be a useful place to start if in future it becomes more important to match the actual meaning of pp dates.

In the meantime, would a warning be helpful, so that users this is affecting have a pointer towards where the bug is coming from in their code that assumes Iris does this correctly?