Balaji,
>
> I like the two-integer approach, but not those particular two. Both
> "days" and "milliseconds" are problematic: "days" are inappropriate
> for non-terrestrial planets, and "milliseconds" a somewhat arbitrary
> subdivision that seems 'small enough' with respect to our currently
> envisaged applications, but which will surely fail for something or
> other (e.g I could imagine a model with a 1/3 second timestep).
I didn't mean to propose that one could only use "days" and
"milliseconds", but that one could use whatever units were allowed by
UDUNITS. And one should be able to use 32-bit or 64-bit integers as
appropriate also, just as they can choose the type of time variable
now.
>
> What I'd propose instead is a two-integer approach, both longs
> (64-bit, that is). The first is the number of seconds since the time
> origin, and the second the number of ticks since the last full second.
> A 'tick' is defined by an integer attribute tick_length (which in your
> case would be 1000) defining an integer fraction of a second
> appropriate to the application.
>
> So there's two auxiliary attributes, time_origin (which, while we're
> about it, we should make a proper attribute instead of parsing from a
> 'time since...' string) and a tick_length.
The "tick_length" seems like a neat solution to the problem of
non-rational times. We shouldn't be locked into 64-bit integers and
"seconds", but can choose whatever is most appropriate, right?
For our time series data, for example, I should still be be able to
use 32-bit integers, with time units of "days" (defined in UDUNITS as
8.64e4 second), and time2 units of "milliseconds", which would be
tick_length=86400000 in your method. And if I had 1/3 second time
steps, I could use seconds with tick_length=3, or hours with
tick_length=10800.
Should we make a proposal on the CF standards Wiki?
--Rich
--
Dr. Richard P. Signell (508) 457-2229
USGS, 384 Woods Hole Rd.
Woods Hole, MA 02543-1598
Received on Thu Nov 01 2007 - 14:07:55 GMT
