netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
"Robert E. McGrath" <mcgrath@xxxxxxxxxxxxx> writes: > From talking with Quincey, I would like to point out a couple of areas > where people might want to look carefully. 1. H5Gmove, etc. > > Technically, time stamps are set when an object is inserted in a group. > And technically, H5Gmove is an atomic (delete, then insert). So it > should > set the time stamp to the time of the move. > > Quincey proposes to not update the time. > > There are arguments for either behavior, so it would be good for > people to > look at this carefully. > I will leave this to you HDF5 programmers. NetCDF doesn't allow moves, so I don't use H5Gmove. > > 2. H5Gset_creation_time > > This is a funny function that let's you manually set the timestamp on > a given link. I'm not sure we need this at this time. > > As far as I know, we don't have any use cases for this feature. > > To me, it is philosophically questionable, because the timestamp isn't > supposed to be > "whatever I want it to be", it is supposed to be "the time I really > did it". > > Also, I can think of at least 2 pernicious uses of this feature: > > a) somebody my use this timestamp as a back door way to create an > arbitrary > numeric index. E.g., compute some statistic in the dataset, and set the > timestamp to that value. Voila! I have an index on that statistic! > > b) somebody might do something horrid like store every record in a > separate > dataset, setting the time step from some source such as a real time > clock > or network time stamp. They are trying to get time sorted records (think > of Boeing, merging multiple real time streams.) This would kind of > work, > but I think it would be a really bad use of HDF5. > > Again, others may well have different opinions, so it would be good for > people to look at this one. I think you should store an index, not a time-stamp. Do not let the user change the index under any circumstances. Ed -- Ed Hartnett -- ed@xxxxxxxxxxxxxxxx