Skip to content

Add a rule to enforce restrictions on time co-ordinates #15

@pont-us

Description

@pont-us

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.

Additional context

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions