Hi John,
I come from an environment of simple pragmatism. Experience has shown that any degree of freedom included in a standard specification wll be expoited to its fullest extent. Combined with this we have a need to build tools to handle SeaDataNet data with a modest software development budget. Cutting out the complexity of working out what the time zone for an 8601 string without explicit time zone or even of including any kind of time zone conversion logic was considered prudent.
Note that my strong preference for the SeaDataNet 8601 profile is to mandate UT strings with explicit labels to show exactly what they are. That way we are both internally and externally interoperable.
Cheers, Roy.
________________________________
From: CF-metadata [cf-metadata-bounces at cgd.ucar.edu] On Behalf Of John Graybeal [jgraybeal at ucsd.edu]
Sent: 19 March 2013 19:28
To: ngalbraith at whoi.edu
Cc: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] New standard name: datetime_iso8601
Use Cases:
1) I am documenting an ISO-8601-compliant time variable from an instrument or application, which I would rather capture in its raw string form than convert to another form.
2) I would like to present some time variable in human-readable form, so that users of netCDF clients that have *not* found the holy grail of time conversions can quickly see whether records are from a time of interest, or are appropriately spaced, or have appropriate resolution, or.... (Note that among those users are people who look at binary dumps of files, of which I am one but I'm sure there are many others.)
Because of use case 1, I do not want to require that the time zone be declared. I think this practice should be encouraged as strongly as possible (even going so far as to include it as a strong recommendation in the definition).
I dislike the 'local standard' approach that Roy mentions, because if I do not happen to be a SeaDataNet member who happens to have been around at that time and received that transmission of "best practices" (or have read it on the web somewhere), if there is a SeaDataNet file that I come across without time zones, I will naturally use the ISO *standard*. In that case, we've created anti-interoperability.
John
On Mar 19, 2013, at 12:08, Nan Galbraith <ngalbraith at whoi.edu<mailto:ngalbraith at whoi.edu>> wrote:
There seems to be surprisingly broad support for this idea, so I've been
re-reading the thread, looking for a reasonable use case. I can't say that
I've found any description of why we actually need this - am I missing
something?
Anyway, going back to Aleksandar's original (slightly amended) proposal of
Jan 11 just for a moment... I'd like to clarify one detail. As far as I know,
ISO 8601 calls for the default time zone to be local, not UTC.
If we're going to add this option to CF, we should *at least* require the time
zone to be specified. Allowing a default, and having that default NOT align
with ISO, is just too much to ask. Either we're implementing ISO, or not -
changing the default meaning of the time zone would truly mislead our
imaginary post-apocalyptic researchers - and I know how much we all
worry about them.
>From Wikipedia (my only available ISO documentation):
Time zones in ISO 8601 are represented as local time (with the location
unspecified), as UTC, or as an offset from UTC.
If no UTC relation information is given with a time representation, the
time is assumed to be in local time.
Cheers - Nan
On 1/11/13 12:00 PM, Aleksandar Jelenak - NOAA Affiliate 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-60).
* "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".
--
*******************************************************
* Nan Galbraith Information Systems Specialist *
* Upper Ocean Processes Group Mail Stop 29 *
* Woods Hole Oceanographic Institution *
* Woods Hole, MA 02543 (508) 289-2444 *
*******************************************************
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu<mailto:CF-metadata at cgd.ucar.edu>
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
----------------
John Graybeal <mailto:jgraybeal at ucsd.edu> phone: 858-534-2162
Product Manager
Ocean Observatories Initiative Cyberinfrastructure Project: http://ci.oceanobservatories.org
Marine Metadata Interoperability Project: http://marinemetadata.org
________________________________
This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130319/37a78a76/attachment-0001.html>
Received on Tue Mar 19 2013 - 13:45:07 GMT
