You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently there are few checks on time co-ordinates. For instance, a plain int64 array with attributes of {"units": "marshmallows"} passes all current checks.
Describe the solution you'd like
First we need to decide what time specifications should be allowed and disallowed.
One obvious restriction is that time specifiers should be timezone-aware; it is hard to come up with a plausible use case for a timezone-naive time co-ordinate, and it tends to cause errors when indexing.
datetime64[ns] is a special case; it's the standard time type used by xarray, it doesn't contain any explicit timezone information, and using it as input to the pandas.Timestamp constructor gives a timezone-naive timestamp. However, a close reading of the NumPy documentation confirms that datetime64 is defined in terms of the Unix epoch, and therefore has an implicit UTC timezone.
When reading a dataset, xarray will automatically decode CF-compliant time specifiers to datetime64[ns] (if possible) or cftime. Should we also support "raw" time co-ordinates with undecoded CF attributes?
What should we support outside of standard xarray practice and CF conventions? e.g. the compliant dataset in the xrlint example notebook has an int64 time co-ordinate with the annotation {"units": "years"}, which follows neither xarray nor CF conventions.
Describe alternatives you've considered
One alternative would be to decide that time co-ordinates are simply too variable and complex to be checked reliably, and to refrain from writing any rules for them.
e.g. the compliant dataset in the xrlint example notebook has an int64 time co-ordinate with the annotation {"units": "years"}, which follows neither xarray nor CF conventions.
While it is perfectly valid to have a dimension comprising years (climatologies) as units, I actually don't now what the correct unit is. Therefore you could write a rule that checks for "correct" time units! In my case, maybe years since 0000-00-00 00:00:00.0000 is correct?
Please consider:
rules can be of type "suggestion" which relaxes their use.
we can define multiple rules for different use cases. Plugins can provide predefined configurations, hence we can write dedicated time rules but not include them in some predefined configurations only, or not at all.
Is your feature request related to a problem? Please describe.
Currently there are few checks on time co-ordinates. For instance, a plain
int64
array with attributes of{"units": "marshmallows"}
passes all current checks.Describe the solution you'd like
First we need to decide what time specifications should be allowed and disallowed.
datetime64[ns]
is a special case; it's the standard time type used by xarray, it doesn't contain any explicit timezone information, and using it as input to thepandas.Timestamp
constructor gives a timezone-naive timestamp. However, a close reading of the NumPy documentation confirms thatdatetime64
is defined in terms of the Unix epoch, and therefore has an implicit UTC timezone.datetime64[ns]
(if possible) orcftime
. Should we also support "raw" time co-ordinates with undecoded CF attributes?int64
time co-ordinate with the annotation{"units": "years"}
, which follows neither xarray nor CF conventions.Describe alternatives you've considered
One alternative would be to decide that time co-ordinates are simply too variable and complex to be checked reliably, and to refrain from writing any rules for them.
Additional context
The text was updated successfully, but these errors were encountered: