Hi John,
I'm probably repeating what others have said, but allowing strings as
actual (rather than ancillary) coordinate values would break lots of
"quick look" software which can't plot variables which are "functions"
of a string representation of the independent variable (i.e, time). If
I'm correct about this, I think making the proposed change to CF would
be a mistake.
If the alternate string representation is stored as an ancillary
variable, a human reading the ncdump would immediately see what the
"dates" are, and the software would continue to work by reading the
actual coordinate values.
Karl
On 3/21/13 8:51 AM, John Caron wrote:
On 3/21/2013 9:41 AM, Steve Hankin wrote:
On 3/21/2013 8:25 AM, John Caron wrote:
Probably my proposal comes down to 2 parts, which are separable:
1. Find a suitable replacement for udunits as a reference library
for CF calendar dates. Unfortunately, udunits used a slightly
non-standard syntax, which we need to still be legal for backwards
compatibility. So its unlikely a standard library would work off the
shelf. Someone needs to commit to making a library that supports CF
as it evolves. Other libraries can test against it.
2. *Allow*
Hi John,
The crux of this debate has been whether to "allow" a new (for CF),
redundant encoding of time coordinates. I *think* you are suggesting
in your bullet #2 to allow the new syntax only in ancillary variables
(metadata), but not as a representation of coordinates. Can you clarify?
- Steve
a suitable string syntax for date/times, probably expressed as a
profile of ISO8601. Its a modest but worthwhile improvement IMO. The
syntax that is already used in udunits would be ok with me. However
this syntax has to be defined (it never was, unless you are yacc).
In my understanding, udunits is more or less a superset of ISO. that
is, its a bit more lenient in the syntax. However it adds a few
restrictions, like defaulting to UTC and filling non specified
fields with 0. So its not strictly a superset. The advantage of
using CF process to define the syntax ("clarify the profile of
ISO8601") is that we are less likely to miss some subtlety in syntax
and meaning.
John
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Hi Steve:
Im proposing that time coordinates may be expressed as strings, in
addition to the current way of using time offsets from a base date
expressed as a string in the unit attribute. The two date string
syntaxes (standalone and in the unit attribute) c/should be the same.
Presumably we want to do either this or Aleksandar's proposal ?
John
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
CF-metadata@cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
