On 3/20/2013 7:58 AM, John Caron wrote:
Hi all:
I guess I started this messy discussion, then invited everyone to
drink too much and say whatever they wanted. The conversation gets a
bit loud and fuzzy. So now we've switched back to caffeine and the
sober realities of deciding on grammars in the context of a specific
proposal that seems to be acceptable to all.
Hi John,
I'm hearing an undercurrent of "last call" in our bar metaphor. Probably
for the best. We've all had quite a bit to drink, eh?
Since there were a lot of "whats the problem" comments, I will just
give my motivation for this topic.
There are two things you want to do with datetimes: 1) specify an
instance on the datetime coordinate axis. 2) compute the time
difference between two instances (a calendar is needed to compute time
differences).
Our current "period since date" representation is better for the
second case. A direct representation of the time instant (like
ISO8601) is better for the first case. _*I suggest we allow both, as a
modest improvement. *_
I think you've captured correctly the "two things we want to do with
datetimes": identify time points and compute time intervals. But I
cannot think of a science dataset where there is an "either/or" choice
between the two. We almost always need to do both. And I'm pretty
sure you are not proposing two redundant encodings in any single file.
So supporting both encodings means that each encoding has to be used for
the thing it does least well, as well as the thing it is well suited
to. The end result sounds like added complexity, without much gain.
Mostly my POV is a library implementer, where the following issues are
in play:
1. It turned out to be a mistake to rely on udunit library for
datetime processing. _*I think we no longer have an official reference
library for this (?).*_
I suspect that you are right. For years non-Java CF clients have each
"rolled their own" to support multiple calendars. In the Java landscape
there has maybe been better convergence on joda-time, but fairly recently.
Is there an "official" Unidata plan on this matter? Clearly it is a
strategic question from the pov of the CF community: _from whence will
well-supported client libraries for netCDF time encodings be coming_?
Should we try to influence Unidata priorities?, or is there a group
within the CF community that is willing to step forward and take on this
piece of work?
2. Non-standard calendars are non-trivial.
Non-standard calendars are not "trivial", but nor are they particularly
difficult. We should think how to get the technical under-pinnings of
this discussion into the open. Do we have a shared understanding of
(say) how a particular formatted date in the proleptic-Gregorian
calendar relates to the same-appearing formatted date in the noleap
calendar? Maybe we should start a separate thread to discuss this.
3. Theres little or no extra work to implement, because we already
have to parse the date string in "period since date" representation.
4. The time instant representation doesnt solve the non-standard
calendar, since you will still want to be able to compute time
differences.
I'm puzzled by 3 & 4??? The libraries need to address the questions
posed above under #2. There's "work" to doing so.
Really the main advantage is that data writers are less likely to make
a mistake specifying
1952-08-15T00:00:00Z
than
2434567 days since -4713-01-01T00:00:00Z.
As others have commented, this claim doesn't ring true for all of us.
In the CF world "data writers" are almost never humans typing date
strings. Since the "data writers" are actually machines, they will not
make mistakes if the underlying client libraries are solid and it is
clear to programmers how to use them.
and you shift the burden of calculating time differences onto the
_*software*_.
The software that should be assuming these routine (but error prone)
burdens is the community-accepted client libraries. Not each separate
application programmer. Clearly if each application were to implement
unique code to handle datetimes, we will have undesirable consequences.
This email thread circles back again and again to the scope and quality
of the available client libraries. I'd argue that the entire topic of
putting multiple time encodings into CF is symptomatic of weaknesses in
the client libraries. The question for all of us then is, where do we
find the resources to write (or update) the datetime libraries that CF
needs?
- Steve
Note that Im just advocating for adding this as an option, not
replacing the current standard.
John
PS: Jonathan asks: "how can we reduce the possibility of these
mistakes"? We need a reference library for datetime that reads CF
files and calculates both instances and time differences, and spits
them out in user-configurable ways so that data writers can double
check that their files are written correctly. It has to handle all the
non-standard calendars that are in CF.
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
