Unpin cftime

[stephenworsley]

Closes #3751.

[stephenworsley]

There still seem to be a few tests failing. I'm not sure if these are due to changes in cftime. The one i've looked into is system_test_supported_filetypes in iris.tests.system_test.SystemInitialTest where it seems that time point is now being loaded from pp as an integer rather than a float. While I haven't found the ultimate cause for this change, I have found a part of the Iris code which seems like it could be responsible for such a discrepancy.

iris/lib/iris/fileformats/pp_load_rules.py

Lines 627 to 649 in 9bc92f7

	def date2hours(t):
	epoch_hours = _epoch_date_hours(epoch_hours_unit, t)
	if t.minute == 0 and t.second == 0:
	epoch_hours = round(epoch_hours)
	return epoch_hours
	def date2year(t_in):
	return t_in.year
	# Check whether inputs are all scalar, for faster handling of scalar cases.
	do_vector = len(t1_dims) + len(t2_dims) + len(lbft_dims) > 0
	if do_vector:
	# Reform the input values so they have all the same number of
	# dimensions, transposing where necessary (based on the dimension
	# mappings) so that the dimensions are common across each array.
	# Note: this does not _guarantee_ that the arrays are broadcastable,
	# but subsequent arithmetic makes this assumption.
	t1, t2, lbft = _reshape_vector_args(
	[(t1, t1_dims), (t2, t2_dims), (lbft, lbft_dims)]
	)
	date2hours = np.vectorize(date2hours)
	date2year = np.vectorize(date2year)

In the above code, round() will give an int while np.vectorize(round)() will preserve type. There will therefore be a discrepancy on load depending on dimensionality.

[bjlittle]

@stephenworsley Awesome, thanks for following through on this, and raising this issue with the cftime community (Unidata/cftime#182), who responded with at 1.2.1 patch fix, see their changlog.

👍 🎉