Historically, time, as separate from the date, isn't a required parameter in WHP Exchange files. It was required in WOCE SUM files.
This had led to the situation where only the date with day accuracy is known for a given profile. While this may be adequate for use cases which look at decadal timescales, it is significantly less useful for looking at processes on the day timescale (e.g. internal tides). As such, how well the date/time of a profile is known should be represented somehow.
I see two options, both assume integer representation of datetime:
use the units attribute to indicate how precisely a time is known, some examples:
If date a time are both known to the minute (case for WOCE files): minutes since 1970-01-01T00:00Z
If a date is present, but time is missing (case for a few WHP Exchange files): days since 1970-01-01
Use some currently unspecified additional attribute to indicate how well known the datetime value is. For example date_precision = "day" or date_precision = "minute" when coupled with units which look like minutes since 1970-01-01T00:00Z.
Option 1 feels "cleaner" to me in that its built into the units and conforms to the current wording in the CF document and both udunits and cftime have no issues with the mixed representation. However, people would need to use a library to interpret the values at all times and could not rely on the actual numeric values in the data variable to be comparable across files.
Option 2 involves users needing to look at another attribute to understand the data. It also allows the units to be consistent across files especially if a floating point datatype is used to represent the time.
Historically, time, as separate from the date, isn't a required parameter in WHP Exchange files. It was required in WOCE SUM files.
This had led to the situation where only the date with day accuracy is known for a given profile. While this may be adequate for use cases which look at decadal timescales, it is significantly less useful for looking at processes on the day timescale (e.g. internal tides). As such, how well the date/time of a profile is known should be represented somehow.
I see two options, both assume integer representation of datetime:
units
attribute to indicate how precisely a time is known, some examples:minutes since 1970-01-01T00:00Z
days since 1970-01-01
date_precision = "day"
ordate_precision = "minute"
when coupled with units which look likeminutes since 1970-01-01T00:00Z
.Option 1 feels "cleaner" to me in that its built into the units and conforms to the current wording in the CF document and both udunits and cftime have no issues with the mixed representation. However, people would need to use a library to interpret the values at all times and could not rely on the actual numeric values in the data variable to be comparable across files.
Option 2 involves users needing to look at another attribute to understand the data. It also allows the units to be consistent across files especially if a floating point datatype is used to represent the time.