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