⇐ ⇒

[CF-metadata] New standard name: datetime_iso8601

From: Dave Allured - NOAA Affiliate <dave.allured>
Date: Wed, 20 Mar 2013 12:13:53 -0600

Correction, I said this yesterday:

> If leap seconds are excluded, then the correct [value of
> the CF calendar attribute] should be "proleptic_gregorian".

In the most common cases where the data is fully within the range of
the Gregorian calendar, the calendar attribute should be simply
"gregorian". In the rare cases of true historical chronology prior to
year 1583, the calendar attribute should be "proleptic_gregorian".
Both of these must prohibit leap seconds, even the assumed existence
of leap seconds within the record span, if consistency with
traditional CF time encodings is to be maintained.

On a related note, I could support datetime_iso8601 as either a
standard name, or a special value for the units attribute.

--Dave

On Tue, Mar 19, 2013 at 6:21 PM, Dave Allured - NOAA Affiliate
<dave.allured at noaa.gov> wrote:
> Aleksandar,
>
> I support this standard name proposal. I like the restrictions on
> syntax and use to a sensible subset for scientific applications.
>
> Unlike most standard name proposals, this is more than a simple
> definition of a physical meaning. You are making a set of technical
> use specifications, with significant departures from the reference
> standard ISO 8601. Will there be a reference archive for the
> particular specifications? Will this reside exclusively in the CF
> standard name table, or in a new CF chapter or appendix, or something?
> I think there needs to be something better than "that CF list
> discussion of January to March 2013".
>
> Please be exact in the specification of the reference calendar. Try
> to eliminate all possible measurement ambiguities. Leap seconds are a
> problem. There are no leap seconds in the standard calendars
> currently defined by CF, and I was not able to locate exactly where
> ISO8601 stands on this issue. I would really hate to see a "Gregorian
> calendar" or proleptic_gregorian implementation with interval
> calculations that differ from the CF defined calendars.
>
> I suggest a requirement that the calendar attribute be included on all
> variables using datetime_iso8601. If leap seconds are excluded, then
> the correct attribute value should be "proleptic_gregorian".
>
> You have "four-digit years". Are you explicitly restricting the spec
> to only years 0000 through 9999?
>
> Thank you for working on this!
>
> --Dave
>
> On Fri, Jan 11, 2013 at 10:00 AM, Aleksandar Jelenak - NOAA Affiliate
> <aleksandar.jelenak at noaa.gov> wrote:
>> Dear All:
>>
>> Here's the modified proposal for the datetime_iso8601 standard name:
>>
>> standard_name: datetime_iso8601
>>
>> Units: N/A
>>
>> String representing date-time information according to the ISO
>> 8601:2004(E) standard. Variables with this standard name cannot serve
>> as coordinate variables. Date-time information is in the Gregorian
>> calendar. For dates preceding the Gregorian calendar the date-time
>> information is in the proleptic Gregorian calendar. Possible date-time
>> string forms are:
>>
>> <datetime> = <date> "T" <time> <timezone> ;
>>
>> <date> = YYYY "-" MM "-" DD | YYYY "-" DDD ;
>>
>> <time> = hh | hh ":" mm | hh ":" mm ":" ss | hh ":" mm ":" ss "." S
>> | hh ":" mm ":" ss "," S ;
>>
>> <timezone> = "" | "Z" | "+" hh | "+" hh ":" mm | "-" hh | "-" hh ":" mm
>>
>> Where:
>>
>> * "YYYY" is a four-digit year (0000-9999).
>>
>> * "MM" is a two-digit month of the year (01-12).
>>
>> * "DD" is a two-digit day of the month (01-31).
>>
>> * "DDD" is a three-digit ordinal day of the year (001-366).
>>
>> * "hh" is a two-digit hour (00-23).
>>
>> * "mm" is a two-digit minute (00-59)
>>
>> * "ss" is a two-digit second (00-59).
>>
>> * "S" is one or more digits representing a decimal fraction of the
>> second.
>>
>> * The value of any designator when not specified is zero.
>>
>> * If <timezone> is ommitted the default value is "Z".
>>
>>
>> -Aleksandar
Received on Wed Mar 20 2013 - 12:13:53 GMT

This archive was generated by hypermail 2.3.0 : Tue Sep 13 2022 - 23:02:41 BST

⇐ ⇒