Hi all:
Another thing to consider is the relationship to the current udunit/CF
standard for specifying dates in the unit string
"period SINCE date"
The udunits documentation
<http://www.unidata.ucar.edu/software/udunits/udunits-2/udunits2lib.html#Grammar>
not being very clear, I wrote up my understanding of current practice here:
http://www.unidata.ucar.edu/software/netcdf-java/CDM/CalendarDateTime.html#ISO_String
Note the paragraph towards the end starting with "with the following
differences, to allow backwards compatibility with udunits:"
as this documents the differences AFAICT that current practice has with
ISO 8601 standard.
It appears that this grammer is slightly more lenient than the one that
Aleksandar proposes.
John
On 3/19/2013 6:21 PM, Dave Allured - NOAA Affiliate 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.jele...@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
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
