I'm still a bit confused about whether this is proposed as an
alternative to or an addtion to, the existing time-since-date approach
-- i.e would creators of CF files need to choose which to use? or
could use both in one file? or does someone want to deprecate the old
way?
Anyway, a comment or two:
On Sat, Feb 23, 2013 at 1:41 PM, John Caron <caron at unidata.ucar.edu> wrote:
>> We already have a way to encode datetimes in CF-netcdf.
>
> Yes, but <time since date> is not as good as <date> as an encoding. The
> <time since date> is a result of cramming calendar handling into a units
> package.
For the record, I have written a fair bit of client code for CF files,
and never once used ud-units. time-since-datetime has other
advantages:
smaller files: each individual datetime is a single double, or float,
or ... not a whole multi-byte string.
most scientific code internally uses something similar: seconds since
an epoch or something to work with time -- it's important for
computation. Some libraries have nice datetime object (I use Pythons a
lot), but when you really need to compute, you usually put in in a
standrad data type.
>> 1) Having multiple ways to encode the same data in file format adds
>> complication to all client code -- client code would need a way to
>> process both ISO strings and "time_unit since datetime"
>
> client code already has to parse the "date" in "time since date". So theres
> no extra code involved.
you still need two code paths for handling the data -- even if you
already have a lib for parsing ISO date strings.
>> As a result, we would be complicating client code, and getting no new
>> functionality.
>
> We get new functionality in that "date" is clearer than "time since date",
> and more likely to be correctly understood by non CF specific software and
> users of our data in 100 years when theres no more CF discussion group to
> help people out.
I suppose so -- though "hours since date time" does read pretty well
-- I knew what it meant the first time I saw it without looking at the
CF docs.
> when you have non-standard calendars, the difficulty is compounded many
> times over. How many seconds since 1970 is April 3, 2045 at 1:13 am in the
> no-leap calendar? Are you sure? What if you could just put into your file
> "2045-04-03T01:13:00" ?? Even rocket scientists can do that ;^)
good point here -- calendars are a nightmare!
> Ideally file encodings should be as independent as possible from libraries
> and applications. We have historically had an unfortunate dependence on the
> udunits reference library for date parsing.
Again, I don't think there is much udunit dependence, you you
certainly aren't going to get away from having to parse ISO
datestrings this way...
> I think in this case widening the allowed encoding for datetimes
> is well worth the complication.
There are good arguments either way -- I've made my points, but don't
have a really major objection here.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker at noaa.gov
Received on Sun Feb 24 2013 - 00:01:57 GMT
