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 <[email protected]> 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
> [email protected]
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata


----------------
John Graybeal    <mailto:[email protected]>     phone: 858-534-2162
Product Manager
Ocean Observatories Initiative Cyberinfrastructure Project: 
http://ci.oceanobservatories.org
Marine Metadata Interoperability Project: http://marinemetadata.org







_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata

Reply via email to