John et. al.,
It looks like this thread has reached reasonable conclusions:
1. units of days (or secs or mins) can provide an accurate encoding
for months ("days since 1930-01-01")
2. "units of measure" should not be quantities that vary
3. udunits could in principle offer calendar type-sensitive support
for units of "months" or "years", but doing so would likely break
backwards compatibility and would get nasty-complicated as a
result of bullet #2
I'd like to add a response to this concern:
option 1 is suboptimal because one has to calculate the days
correctly. Also it makes the time coordinates not human readable, eg:
Here I think concerns of human-readable formatting and convenience are
sliding into issues of accurate encoding. ncdump already offers an
option to format these values as dates. Ncgen could in principle offer
conversions to encode various human-friendly formatting options.
The larger question of "months" used as units of time measure is an
ingrained problem of sloppy earth science. =-O >:o (heresy!) Regarding
Gregorian months (unequal length) as a simple numbered sequence, 1, 2,
3, 4 .... continues to promote countless sloppy (wrong) calculations --
erroneous derivatives, integrals, variance, ... any calculation that
attempts to use the month number as encoded as a unit of time measure.
Glossing over these errors seems often to be the norm, rather than the
exception. This is one of those rare areas where our responsibility as
software developers should be to push back against sloppy science, by
offering software that makes it easy to do the calculations correctly,
and help to end these sloppy practices. I'd welcome seeing this
discussion elevate to our science colleagues.
- Steve
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
