On Nov 2, 2007 3:05 PM, Steve Hankin <Steven.C.Hankin at noaa.gov> wrote:
>
> You can probably guess the drums that I'll be beating:
...
> One advantage cited for the two-integer encoding was "avoiding round off
> problems where you get 23:59:59 instead of 00:00:00" Can we clarify?
We've run into this in the past the time step is a non-regular number
(a number that has an infinite decimal expansion, like Balaji's
example of 1/3 second time steps). When you convert from decimal days
to gregorian time, you can get these round off errors giving you
2007-12-31 23:59:59.99 instead of midnight.
> The use case that Rich presented is "millisecond precision over millennia,
> so you can do things like paleo earthquake simulations". Sounds
> interesting ... but a new requirement to me. Are there use cases where a
> single "file" (or aggregation) needs to contain millisecond precision over
> millennia time scales? Are there alternative ways to structure the data
> that might work as well?
If you need millisecond accuracy, a 32 bit integer only gives
(2^32)/(24*3600*1000)= 49.7 days.
Regarding the beating drum of interoperability, it seems likely that
clients will be using some sort of library to achieve
interoperability with CF time conventions (currently UDUNITS, perhaps
something else in the near future) and that it would be trivial to add
to the library handling of the two-variable time case in addition to
the single variable time: just process the first variable as currently
done, then add on the 2nd variable divided by the "tick_length"
attribute.
Should this be moved to the wiki? I didn't actually make a proposal,
but I feel that the thread history on the issue of allowing a
"two-integer time convention" is getting harder to follow.
-Rich
--
Dr. Richard P. Signell (508) 457-2229
USGS, 384 Woods Hole Rd.
Woods Hole, MA 02543-1598
Received on Mon Nov 12 2007 - 14:06:12 GMT
