Type of time_coverage_start and time_coverage_end

[marack]

The time_coverage_start and time_coverage_end variables are currently specified as strings, which is not very "CF" like. The standard way of representing a time is as a numerical offset from an epoch.

I would like to change the type of these variables from string to double and specify them as times in the traditional CF manner. This allows the variables to be used with existing functions for dealing with times in NetCDF files.

The new specification could be as type double, with units seconds since YYYY-MM-DD HH:MM:SS UTC. Where the exact YYYY-MM-DD HH:MM:SS time is up to the user.

As part of this change I would also like to remove the comment that the 'T' character in the ISO8601 spec is optional and can be replaced by any character. As far as I can tell the character may only be 'T' or whitespace.

The duplication of these variables as attributes is also a bit awkward. When writing an API to deal with the file, should you read the attribute or the variable? What should happen when they don't agree? I think this was originally done for convenience of users, but I'm not sure it's necessary. If using the standard time representation above, the value can easily be viewed by users with 'ncdump -t'.

To summarize:

1. Can we change time_coverage_start and time_coverage_end from string to double with the standard CF time units?
2. Can we remove the comment that the date/time separator 'T' can be any character? It should be 'T' or a space only.
3. Can we eliminate the duplicated attributes which introduce the possibility of self-inconsistency in the file by having different variable and attribute values?

[kenkehoe]

I second this change.