Better adoption of ISO8601 time standard

[d70-t]

Properly referring to timestamps can be troublesome as many different writing schemes exist throughout the world. ISO8601 was made for the rescue but still offers great flexibility, which might be a bit too flexible for what we need. However, adopting the standard as close as possible seems to be an important step forward.

This issue is to collect and resolve problems which arise with the adoption of IS8601. Please comment if you have suggestions or see other issues.

formatting of times

ISO8601 allows to format times with or without colons, e.g. hh:mm:ss and hhmmss are both valid. Should we use:

• hh:mm:ss
• hhmmss

YAML and W3C for example require colons, but colons tend to be problematic in certain places (e.g. filenames).

formatting of dates

This is closely related to the one above, ISO allows:

• YYYY-MM-DD
• YYYYMMDD
  and again, YAML and W3C require the former. However, in this case, the hyphens usually are less problematic in filename, so this issue could be easier to resolve.

formatting time intervals

ISO8601 provides several methods to format time intervals. An interval can be specified either by start and end or a duration and one of start or end. To separate the two, ISO8601 specifies the use of a forward slash /. E.g. start/end or start/duration or duration/end. The forward slash is however also a problematic choice with respect to filenames, and a double hyphen -- seems to be popular in stead.

• should we adopt ISO8601 time intervals at all?
• should we allow the definition of durations? - or only the start/end format?
• which separator should be used?

[heikekonow]

Regarding the format of times and dates, I have the feeling that there is no perfect solution. We will probably have to convert either way. If we choose hh:mm:ss, this will work well with yaml, but we will have to convert this for file names (same for YYYY-MM-DD vs. YYYYMMDD). If we chose the other, we'd have to convert to use in yaml, etc.
Therefore, I would vote to just chose one and live with the fact that we have to do some kind of conversion. I would only suggest, that we chose the similar formats in times and dates so that the conversion has only to be done in one direction. So, for example, use hh:mm:dd together with YYYY-MM-DD or the other way round.

I haven't come across the need for durations yet. So I have no opinion on this.

[d70-t]

My general opinion on filenames is roughly like "I don't really care and apart from being unique, they should not really matter." A consequence from that might be that we should prefer to make parsing libraries happy (i.e. YYYY-MM-DDTHH:MM:SS) and strip bad characters as necessary when creating filenames, as in the end, no one should try to read back information from the filenames anyways.

I've not come across libraries for parsing time periods yet, but having the possibility to do so seems to be quite useful. Maybe @leifdenby has an example for that?

[RobertPincus]

@d70-t Where would this standard be applied? I understood that time, like all variables, should be represented internally following the CF conventions. If the question is file name formatting then colons are certainly unfriendly. Where else?

[d70-t]

Things which come to my mind are

• within separate metadata files
  • that can be either the YAML files which are currently handwritten and which may or may not end up in this repository
  • other generated formats which will emerge (I think of JSON data which could be assembled and served over HTTP or returned by some search APIs later on?)
• times also tend to appear within netcdf attributes. I am not aware that CF conventions tell anything about times which are not within variables, one could argue though, that times should never be stored as attributes
• human readable reports
• file names