time units in CORDEX-CMIP6 archiving specs

[jesusff]

The specs currently state that:

The unit of the time coordinate is days since 1950-01-01T00:00:00Z or days since 1950-01-01 for all files

This unit formatting as a timestamp (instead of e.g. days since 1950-01-01 00:00:00) is inherited from the previous CORDEX (-CMIP5) specifications.

While CF delegates the interpretation of the time units to the udunits2 library, the examples given in the CF conventions for these units use the days since DATE CLOCK formatting. Also, I couldn't find any file from CMIP6 or CORDEX(-CMIP5) formatted using the days since TIMESTAMP format suggested in the archiving specifications. I wonder whether the CMOR library is automatically writing the time units in a DATE CLOCK format.

So, even though udunits2 seems to accept the timestamp formatting, we might consider updating the CORDEX-CMIP6 archive specs to the actual use of these units in the output files.

ping @gnikulin @larsbarring

[jesusff]

In CMIP6, they just skip the time of the day in the time units examples, e.g. days since 1950-1-1 https://docs.google.com/document/d/1os9rZ11U0ajY7F8FWtgU4B49KcB59aFlBVGfLC4ahXs/edit#bookmark=id.sv0qr44ynpy4

[larsbarring]

I cannot comment on CMOR or the archiving specification, but on a more general level there is a subtle distinction to be aware of.

According to ISO-8601 (From Wikipedia) omission of the time part indicates reduced precision:

For reduced precision any number of values may be dropped from any of the date and time representations, but in the order from the least to the most significant. For example, "2004-05" is a valid ISO 8601 date, which indicates May (the fifth month) 2004. This format will never represent the 5th day of an unspecified month in 2004, nor will it represent a time-span extending from 2004 into 2005.

However, CF states in Section 4.4:

The reference date/time string (appearing after the identifier since) is required. It may include date alone, or date and time, or date, time and time zone. If the time zone is omitted the default is UTC, and if both time and time zone are omitted the default is 00:00:00 UTC.

Regarding the specific formatting of the DATE and CLOCK part, in CF there is preference to omit leading zeroes and use instead of "T" as separator between the DATE part and CLOCK part. UDUNITS-2, however, accepts both these according to the unit grammar.

From my own perspective I think that it is better to be explicit than implicit and include the CLOCK part, in particular as there is this discrepancy between CF and ISO. And as UDUNITS-2 accepts the ISO format I see no harm in following that, especially as a test file passes two different cf-checkers.

[jesusff]

Thank you, @larsbarring Just to clarify, in this key sentence:

... in CF there is preference to omit leading zeroes and use instead of "T" as separator ...

you mean:

... in CF there is preference to omit leading zeroes and use space instead of "T" as separator ...

right?

Regarding the omission of leading zeros, this is also a discrepancy with the ISO, as the ISO does not allow to omit leading zeros:

Each date and time value has a fixed number of digits that must be padded with leading zeros.

@larsbuntemeyer, could you confirm whether the CMOR library has a specific format hardcoded for the time units origin?

[larsbarring]

Yes, indeed

... in CF there is preference to omit leading zeroes and use space instead of "T" as separator ...

it is. Thanks for spotting this.

[gnikulin]

just checking this issue I noted that the global attribute creation_date has form of YYYY-MM-DDTHH:MM:SSZ in CMIP5 and 6 and in CORDEX-CMIP5 and CORDEX-CMIP6. Of course it's not the time units.