Hey karl - not sure about "best practices" but what I've done, which seems to work pretty well so far, is indeed to use compound types, with the first element of the struct being time. This works well for our application, where we may be recording several thousand distinct channels that can be regarded as asynchronous, and hence each of the packet tables storing the channel data carries its own timestamp in the table entries. Only thing to watch out for is that you cannot store bit-sized parameters inside a compound type, see my post http://hdf-forum.184993.n3.nabble.com/Possible-to-pack-bit-types-into-compound-data-types-td1131024.html#a1168717 for an example of the problem (and a very basic example of a compound type). For our application, it's hard to see how we'd store time any other way, since each record in the packet table arrives unpredictably, so referencing some "other table" would just add complication storage - arrival time is an essential property of the data itself. Cheers Steve -- View this message in context: http://hdf-forum.184993.n3.nabble.com/Best-practice-for-timeseries-and-storing-timestamps-in-Packet-Table-API-tp2104069p2104301.html Sent from the hdf-forum mailing list archive at Nabble.com.
_______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
