Hi Ben,
First of all, you are spending a lot of time talking about what many
of us think as the parsing of the offset in the units string when it
is passed to udunits, which makes it seem like a side issue, probably
unfairly.
ISO8601, as pointed out before, is not designed as a science standard,
it is a business exchange standard, so they can get away with
1) first deciding to skip year 0000, then changing their minds and
insisting on year zero (Note that xSchema dateTime was based on the
earlier choice, so it continues to skip year zero).
2) ISO8601, according to
http://en.wikipedia.org/wiki/ISO_8601, is
proleptic_gregorian, by mutual agreement. Also, one can put more
digits in the year, again b y mutual agreement. That is not exactly
what one expects from a time representation standard for science,
which needs things stately clearly or left undetermined. They do say,
however, that time should be continuous at the day granularity, which
forces the conclusion, mutual agreement or not.
Note that XML Schema merely says there is no year 0000
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/. Whether they
mean by this is that earlier times should be represented by year -2
when ISO8601 says year -1, or they mean you cannot represent just year
0000, or you cannot represent times before year 0000, is hard to say.
Aren't commercial standards wonderful?
So it would seem that conforming to ISO8601 would require proleptic
gregorian calendar support, not in the concrete sense of parsing a
udunits string but in the more general sense of a continuous numeric
representation of time corresponding to ISO8601. And the "standard"
calendar in udunits is not actually the "standard" calendar of
ISO8601. So it would seem that at least proleptic_gregorian support
in udunits is essential for future ease of use.
Benno
On Mon, Nov 1, 2010 at 1:36 PM, Ben Hetland <ben.a.hetland at sintef.no> wrote:
> On 30.10.2010 01:35, John Caron wrote:
>> 1) no one is suggesting to replace the udunits convention; the
>> original suggestion a few years back was to allow ISO 8601
>> formatted time strings in addition.
>>
>> 2) Udunits accepts ISO Strings for the date part, AFAIU, but
>> allows more variations I think.
>
> Yes, or at least this would be a good principle to follow. Alas, Udunits
> lacks a bit to fully accept any ISO 8601 timestamp, even if only the
> date part is considered. For example, a date like "20101101" is accepted
> neither as DATE nor as TIMSTAMP (sic) according to the referenced
> Udunits-2 unit grammar, AFAICT.
>
> I suppose this is also a question of amending the Udunits library itself
> so that full ISO 8601 compliance is achieved. This is something that
> would also make it more suitable in a number of other applications
> besides the netCDF-related ones, I suppose.
>
>
>> The formal grammar is here:
>>
>> http://www.unidata.ucar.edu/software/udunits/udunits-2/udunits2lib.html#Grammar
>
> Thanks for the link!
> (I was aware of it, but wasn't sure whether it applied to Udunits-2
> only, or just Udunits in general...)
>
>
>> 3) ?The problem with udunits time handling is that it doesnt handle
>> anything other than the default Calendar. So, it cant be used as the
>> reference implementation for non-standard Calendars.
>
> I believe the same "problem" exists with ISO 8601 as well.
>
> I also think that adding calendar support is an issue that should be
> introduced with great caution. Calendars are location and culture
> specific, and even when dealing with historical or culture-specific
> dates (how applicable is that to CF?) one needs quite a bit of
> additional meta information to clearly deal with such a "calendar time
> scale".
>
> For scientific usage, I would claim that while any such time scale can
> definitely be useful, one would still sooner or later need to convert
> that "time unit" into something that can be related to _other_ time
> scales, at least if sharing and reuse of data is a concern (which it
> should, IMHO!). To me, it seems that the only internationally accepted
> common standard, or de facto "reference time scale", is the current
> Gregorian calendar. It is often used in parallel with other calendars.
> If data in _other_ calendars (i.e. "time scales") were to be specifiable
> in CF, then at least some means of unambiguously mapping them to
> "Gregorian ISO 8601" would need to be settled.
>
> --
> Regards,
> ? ? ? ?-+-Ben-+-
>
> Opinions expressed are my own, not necessarily those of my employer.
> _______________________________________________
> 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
Received on Mon Nov 01 2010 - 15:15:18 GMT
