Giving a crazy `coord("time").valid_range` changes time points to huge values and produces OverflowError at coord load point

[valeriupredoi]

Hey guys, hope you guys doing well, been a while since I stopped by :smile:

Here's an odd one, this is the toy code that reproduces the issue:

import iris
import iris.coord_systems
import iris.fileformats
import cf_units
from cf_units import Unit
import numpy as np

def _create_sample_cube():
    """Create a quick CMOR-compliant sample cube."""
    coord_sys = iris.coord_systems.GeogCS(iris.fileformats.pp.EARTH_RADIUS)
    cube_data = np.ones((1, 2))
    time = iris.coords.DimCoord([
        100,
    ],
                                standard_name='time',
                                units=Unit('minutes since 1982-01-01 00:30:00',
                                           calendar='gregorian'))
    lons = iris.coords.DimCoord([1.5, 2.5],
                                standard_name='longitude',
                                units='K',
                                coord_system=coord_sys)
    coords_spec = [(time, 0), (lons, 1)]
    cube = iris.cube.Cube(cube_data, dim_coords_and_dims=coords_spec)
    cube.coord('time').attributes["valid_range"] = [1982, 1989]

    return cube

cube = _create_sample_cube()
iris.save(cube, "cow.nc")

this will save the cube to :cow: .nc no problemo but at load point, when trying to access the time coordinate, one will get this nastiness:

OverflowError: time values outside range of 64 bit signed integers

because the value for the core point for time saved is:

DimCoord(array([-9223372036854775806]), standard_name='time', units=Unit('minutes since 1982-01-01 00:30:00', calendar='standard'), var_name='time', attributes={'begin_date': '1982', 'begin_time': '1982', 'time_increment': '1982', 'valid_range': array([1982, 1989]), 'vmax': '1982', 'vmin': '1982'}

Not giving it a valid_range (commenting out that attr assignment line) results in a decent time point - 100, as given in the cube constructor. Or giving it sane range, say [50, 100] will result in nice behavior too - my point is, is there any way a valid_range is checked inside iris before adding it so that time points don't get badly malformed if the range is crazy? Either toss a warning and not change the core points, or toss an error so the user knows what's happened, rather than silently change the core points to cray values :grin:

Cheers muchly for your work, guys :beer:

[trexfeathers]

I'm afraid I need to un-assign myself as my task list is over-full at the moment. Anyone else in @SciTools/peloton available to investigate?

[valeriupredoi]

@trexfeathers you have a team called Peloton? :bicyclist: :laughing:

[trexfeathers]

@trexfeathers you have a team called Peloton? 🚴 😆

😁 there is a good reason behind it. Making the Peloton public is one of the things on my task list!

[wjbenfold]

Can you confirm the versions Iris and other libraries that you're using @valeriupredoi ? I can't reproduce this with Iris as it stands on main (3.3.dev0), indeed I get a lovely little warning: UserWarning: Gracefully filling 'time' dimension coordinate masked points

[github-actions[bot]]

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.

[github-actions[bot]]

This stale issue has been automatically closed due to a lack of community activity.

If you still care about this issue, then please either:

• Re-open this issue, if you have sufficient permissions, or
• Add a comment stating that this is still relevant and someone will re-open it on your behalf.