Quoting from
http://www.iso.org/iso/support/faqs/faqs_widely_used_standards/widely_used_standards_other/date_and_time_format.htm
which says things like
*Example: *2003-04-01 represents the first day of April in 2003.
*Example:* 2003-04-01T13:01:02 represents one minute and two seconds after
one o'clock in the afternoon of 2003-04-01.
Of course, it goes on to say
ISO 8601 does not specify the exact meaning of its representations. This
means for example that the standard does not define whether 09:00 refers to
the exact end of the ninth hour of the day, any other point in the following
minute or the minute as a whole. Users of the standard must agree on a more
exact interpretation of the representation if this is relevant.
So in the end they abdicate. So I'll back off, and say IMNSHO one must
always specify both aspects of time, and the ISO8601 is a lovely string
format for cleanly doing precisely that -- any ISO8601 string should be
interpreted "as a whole"
Benno
On Fri, Mar 18, 2011 at 3:05 PM, John Caron <caron at unidata.ucar.edu> wrote:
> hmm, where do you see that part about "the iso8601 string implies a moment
> and a width a.k.a resolution". i was reading it that the duration = width
> spec was separate.
>
> in any case, this probably highlights the need to be specific about what CF
> semantics are.
>
>
> On 3/18/2011 12:27 PM, Benno Blumenthal wrote:
>
> It is worse than that -- though the local time of the standard creates a
> problem for us -- according to the iso standard, if time is omitted, the
> string corresponds to the whole day, not the start of the day -- ISO8601 is
> a time *interval* standard -- the iso8601 string implies a moment and a
> width a.k.a resolution. For example, 2001-01-01/07 is the first week of
> 2001 is an ISO8601 string. This is an "excellent" time representation, and
> an essential characteristic of a good time representation, but does not map
> well into software that only holds an instantaneous time, or even XML Schema
> for that matter. CF, of course, has bounds, so that the edges of the time
> interval can be specified.
>
> Benno
>
> On Fri, Mar 18, 2011 at 1:23 PM, Jon Blower <j.d.blower at reading.ac.uk>wrote:
>
>> > Just so you know, the UDUNITS package does assume the first day of the
>> > year at 00:00:00 UTC if additional resolution time-fields are omitted.
>> > This conforms to the ISO standard.
>>
>> Actually (according to Wikipedia at least) the ISO8601 standard assumes
>> local time if the time zone is omitted. I'm not sure what time information
>> (if any) is inferred if the ISO string omits hours/minutes/seconds (i.e. I
>> don't think 2008-01-01 is inferred to be the same as 2008-01-01T00:00:00Z).
>>
>> But it's important to highlight that UDUNITS does assume midnight UTC if
>> no time is provided. It implies that the temporal resolution is not to be
>> inferred from the length of the UDUNITS time string.
>>
>> Jon
>>
>> -----Original Message-----
>> From: cf-metadata-bounces at cgd.ucar.edu [mailto:
>> cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Steve Emmerson
>> Sent: 18 March 2011 17:14
>> To: cf-metadata at cgd.ucar.edu
>> Subject: Re: [CF-metadata] udunits handling of fuzzy time units
>>
>> Martin,
>>
>> On 03/18/2011 04:11 AM, Schultz, Martin wrote:
>> > PS: I do disagree with Christopher when he says ''"30 days since 31 Jan
>> 2008" is perfectly well defined.'' - do you refer to 00 UTC or 12 UTC on 31
>> Jan 2008? Or even 00:00 UTC or 01:02:30.3625132 h UTC? OK: if you define an
>> "oceanographic calendar" (where anything shorter than a day doesn't matter),
>> you could have a rule that all hours, minutes, seconds, milliseconds, etc.
>> are mapped onto one value (say 00:00:00 h UTC). But you will need to define
>> this rule in order to give a meaning to your calendar.
>>
>> Just so you know, the UDUNITS package does assume the first day of the
>> year at 00:00:00 UTC if additional resolution time-fields are omitted.
>> This conforms to the ISO standard.
>>
>> Regards,
>> Steve Emmerson
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
>
>
>
> --
> Dr. M. Benno Blumenthal benno at iri.columbia.edu
> International Research Institute for climate and society
> The Earth Institute at Columbia University
> Lamont Campus, Palisades NY 10964-8000 (845) 680-4450
>
>
> _______________________________________________
> CF-metadata mailing listCF-metadata at cgd.ucar.eduhttp://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
--
Dr. M. Benno Blumenthal benno at iri.columbia.edu
International Research Institute for climate and society
The Earth Institute at Columbia University
Lamont Campus, Palisades NY 10964-8000 (845) 680-4450
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20110318/47d88642/attachment-0001.html>
Received on Fri Mar 18 2011 - 13:19:43 GMT
