Pre-emptive adoption of date_microseconds in iris-cf_units

[cpelley]

Setting iris.FUTURE.date_microseconds = True, as described in https://scitools-iris.readthedocs.io/en/stable/whatsnew/3.11.html#v3-11-1-19-dec-2024, would use this change before it became compulsory as well as suppress the logging related to this upcoming change.

However, metoppv/improver is primarily a repository of post‑processing applications. The import of iris is typically deferred until a specific application module is loaded. Users assemble workflows from these applications in a broader context and may also develop and use project‑specific applications outside of metoppv/improver. As a result, it is difficult to predict where and when iris will be imported, and therefore when this global future toggle would actually take effect. Users would need to know to import improver before any of their own code imports iris, or otherwise set the future toggle themselves. This is precisely why these FUTURE flags are intended to be controlled by users rather than set within libraries.

For this reason, setting the global iris.FUTURE.date_microseconds flag within improver (at least as a global flag) itself isn't necessarily the only/best option. At best, metoppv/improver could use a context‑manager approach to enable the future behaviour within individual applications. Even then, the more fundamental change could be to ensure that improver can accommodate differences in timestamp precision during testing, both with and without microsecond support in iris-cf_units.

Possible handling:

• Filter the relevant log messages within project workflows (e.g. EPP, improver_suite).
• Assess the impact of user‑ or project‑level configuration of iris.FUTURE.date_microseconds on metoppv/improver tests, identifying which tests fail. Ideally, improver should be robust to precision changes of this kind—perhaps it already is.
  • Once improver can accommodate these precision differences, individual projects (such as EPP or improver_suite) can choose to enable the future toggle at their own level.
  • This is already a requirement for improved dependency management.
• Configuration of iris, meaning to ditch deferred import of iris/numpy when importing improver (see Do we really need enfore deferred imports within metoppv/improver codebase? #2320).

[JoshuaWiggs]

Even if we decide not to handle these configuration options inside improver, it would probably be a good idea for us to provide some recommendation around how we are expecting them to be handled in our docs. That could just be to say that from improver's point of view we don't care how they are set.