Adopt minimum ISO units for time related elements

[jcermauwedu]

moderator: @OceanGlidersCommunity/format-maintainers
requestor: @jcermauwedu

Is your feature request related to a problem? Please describe.
The units for time related variables and coordinates seems to restrictive and does not use of the full CF time specification.

units = “seconds since 1970-01-01T00:00:00Z”;

Using time stored at this epoch sometimes leads to data handling issues (overflow) when there is a need to convert this epoch to nanoseconds. Some glider processing packages circumvent this issue by moving to an epoch of 1990-01-01T00:00:00. Some sensors/datasets might need to utilize nanosecond precision between data points. It is hard to imagine at this point, but I think a sensor in the future will get there soon enough, so why not build the flexibility in now before we get too far.

Is this related to a specific platform models
Platform agnostic. This is more of a upstream data management / processing issue.

Describe the solution you'd like
The time format should be at a minimum ISO 8601 parsable and can be checked via the compliance checker.

Describe alternatives you've considered
Adopt flexibility of defining time units using the CF time coordinates definition from section 4.4. This would then require utilization of udunits as part of the compliance checker. I have not encountered a Rust equivalent of udunits-2. So, I would defer to at least support ISO 8601 at a minimum.

Additional context

See ncdump -t. The -t option allows display of ISO time leveraging the specified units.
REF: https://www.unidata.ucar.edu/software/netcdf/workshops/2009/utilities/Ncdump.html

CF Section 4.4: time coordinate definition
REF: https://cfconventions.org/cf-conventions/cf-conventions.html#time-coordinate

Rust implementation of ISO 8601 parser
REF: https://docs.rs/iso8601/latest/iso8601/

[jenseva]

Hi Rob,

@jcermauwedu thanks for your comments about the time units.

We met today to review these open issues and agree the docs need to be updated related to time units.

In the section Location Variables > Coordinates > Time our intention is to follow more of the CF approach to time units, but that is not clear in the documentation. We will work on updating the doc to reflect this. I think our intended approach is in line with your suggestion.

Thanks for suggesting a solution that should work within the present constraints of the checker. @castelao What are your thoughts on this as it relates to adding flexibility in the checker for CF/udunits compliant dates (or at least providing flexibility to use ISO-8601)?

The ability there may impact how we update the guidance in the manual.

Note there are some date/time fields where we do have the intention to standardize on seconds since 1970. It looks to me like this would be the case for the GPS_TIME and DEPLOYMENT TIME variables. Resolution should not be an issue with these. I see value in standardizing the units on the GPS_TIME variable, but maybe there are other considerations we are missing. Please chime in if you have an opinion!

Best,
Jenn

[castelao]

I agree with @jcermauwedu suggestion. I think it is a mistake to use a fixed reference time, but instead we should use a strongly defined way to define time (as @jcermauwedu suggests).

It's possible to link with the udunits C-library, and that would be probably the best way to keep up with future changes. Independent of that, I think that current limitations on the tools should not restrict a good standard design. I support this change, and if approved, I'll make the checker to conform.