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
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130320/f76eaf99/attachment-0001.html>
Received on Wed Mar 20 2013 - 17:02:59 GMT
