[CI Bot] environment lockfiles auto-update

[scitools-ci]

Lockfiles updated to the latest resolvable environment.

If the CI tasks fail, create a new branch based on this PR and add the required fixes to that branch.

[pp-mo]

I think this relates to a change in cf-time 1.6.4 ->1.6.5
and probably it was this issue fixed here

Probably, we need to accept that this was wrong before, and change the CML to reflect the new result.
But I'm pausing until I get time to consider this properly -- it could be an error introduced, rather than an intended change from the fix

[trexfeathers]

I think this relates to a change in cf-time 1.6.4 ->1.6.5 and probably it was this issue fixed here

Probably, we need to accept that this was wrong before, and change the CML to reflect the new result. But I'm pausing until I get time to consider this properly -- it could be an error introduced, rather than an intended change from the fix

Have confirmed. During the failing test, date2num() in the below code is returning a number exactly 48 hours - 2 days - different to what it was previously. This is despite all the arguments remaining the same:

iris-grib/src/iris_grib/_grib1_legacy/grib_wrapper.py

Lines 643 to 654 in 542e3dc

	def phenomenon_points(self, time_unit):
	"""Return the phenomenon time points.
	As offsets from the epoch time reference, measured in appropriate time units.
	"""
	time_reference = "%s since epoch" % time_unit
	return float(
	cf_units.date2num(
	self._phenomenonDateTime, time_reference, cf_units.CALENDAR_GREGORIAN
	)
	)

That precisely matches the description of the bug, where operating on non-proleptic-gregorian datetimes was incorrectly relying on the default Python datetime handling rather than anything specialised. We even have the same calendar as the examples in the bug report (standard/gregorian).