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 <[email protected]> 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 [email protected] _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
